Is there a Mathematician Cryptographr in the House.
in [Cryptography]
|
Prev: fire seal with video
Next: Last Call for Papers Reminder (extended): World Congress on Engineering and Computer Science WCECS 2010
From: Sebastian on 19 Jul 2010 05:46 On 19 Jul., 10:04, adacrypt wrote: > [...] On your website you state that you read lots of books on cryptography but liked Simon Sigh's "The Code Book" the best. What other books did you read exactly ? As for public key cryptography, it seems Simon Sigh's book at least introduces the concept -- judging by the table of contents. Did you forget about that ? Maybe you should re-read that chapter... In one of your PDFs you state that we need perfect secrecy. Your reasoning is that someone might discover new algorithms or build new machines that handle a full brute-force search in a key space of 256 bits in a couple of minutes. Well, as for "algorithms": Smart people constantly try to break ciphers. Ciphers are often designed with a "security margin" to account for "unexpected attacks". The advances there are rather slow and even if a cipher is broken that doesn't imply that the attack has any use in practice (yet). But it is a warning and a good enough reason to think about new designs. As for the machines cracking ciphers, I'm no physics expert but I'm aware of physical arguments involving real lower energy limits (see http://en.wikipedia.org/wiki/Brute_force_attack ) for just representing the sequence of keys in a brute-force attack in memory (without actually doing anything else). These energy levels are so high with key sizes of 128 bits or above that there is simply no way for an attacker to come up with that. Double your key size (256 bits) and you get a security margin that is *way* above high enough. So, I think your assessment of the security situation is far too pessimistic. If I have to choose between ciphers that don't provide perfect secrecy (by Shannon's definition) but have a high security margin and a large enough key space and another cipher that provides perfect secrecy, I'll go with the former. Simply because we already know that perfect secrecy implies keys that are as long as the messages and must not be reused. For almost every application this is unacceptable. Ok, ignoring that perfect secrecy ciphers are painful to use correctly due to the large one-time keys, what exactly is it that makes your approach any better than the plain one-time pad algorithm? I don't see any benefits. Only disadvantages. For example, it looks like your ciphertexts are much larger (take up more memory) than the plaintexts. Correct me if I'm wrong. So, what's the deal here? Why bother with a convoluted algorithm that is not any better than the plain OTP ? Cheers! SG
From: Mok-Kong Shen on 19 Jul 2010 10:38 adacrypt wrote: > Mok-Kong Shen wrote: >> You described you scheme using terms in a way that IMHO make your stuff >> very difficult to comprehend. Why couldn't you once use a 'concrete' >> example with actual numbers (like 5, 333 etc.) to explain how your >> scheme really works? (Please indicate thereby which are the secret >> values that are unknown to the analyst and that he has to figure out to >> break the scheme.) > Hi, will do in time - very busy right now - adacrypt. If you don't manage to do that in the coming few days, then please notify me also via e-mail when you finally do answer, for otherwise I may miss that (I normally don't check threads that become quiescent for some time). Note that, if you can provide a good numerical example, then much arguments from you and from others of the group would be unnecessary IMHO. M. K. Shen
From: adacrypt on 19 Jul 2010 11:20 On Jul 19, 3:38 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > adacrypt wrote: > > Mok-Kong Shen wrote: > >> You described you scheme using terms in a way that IMHO make your stuff > >> very difficult to comprehend. Why couldn't you once use a 'concrete' > >> example with actual numbers (like 5, 333 etc.) to explain how your > >> scheme really works? (Please indicate thereby which are the secret > >> values that are unknown to the analyst and that he has to figure out to > >> break the scheme.) > > Hi, will do in time - very busy right now - adacrypt. > > If you don't manage to do that in the coming few days, then please > notify me also via e-mail when you finally do answer, for otherwise I > may miss that (I normally don't check threads that become quiescent for > some time). Note that, if you can provide a good numerical example, > then much arguments from you and from others of the group would be > unnecessary IMHO. > > M. K. Shen Hi,Worked Example - Using my methods: Lets say I want to set up a crypto scheme that will enable any message length from one to 14250 characters long (as an arbitrary figure), to be encrypted. I will need two key sets of that same length also. There are two random key sets required i.e. the keypad formed from multiples of the ASCII subset and the set of moduli being called Ns Then minimum value that X may take = 14250 + 63 = 14313 in the formula that follows. i.e. X is initialised at 14313. The set of Ns as moduli. N belongs in the range (X +127) to 2(X+32) i.e. 14440 to 28690. Checking, 28690 14440 = 14250 => the keyset of Ns is 14250 (ok) The set of keys being called Key. This key set is created ad hoc at runtime by the computer reading in the message for encryption and then calculating the number of multiples of the 95 elements of the ASCII printable subset that will be needed to provide an adequate key-length (this may require some padding of the message to bring the two to be equal in length. Both of these key sets are read into the empty, waiting to be filled, arrays of the program software. At runtime the program will call the elements of each key array in sequential order as required, the arrays are volatile and will empty themselves at the end of the program run. The arrays are scrambled and sliced according to parameters that Alice alone decides. Bob follows her instructions to stay in sync. X as a key. In theory X is a key also but no great reliance of crypto strength is ascribed to it by me because of it being a constant but it does count as a stumbling block to some degree to an adversary. Note: This version of the cipher plans ahead as a general modus operandi that permits many message lengths. It could also be arranged that each message length is calculated at run time and dedicated keys of the bare key-length are used - this as an added foil to cryptanalysis. How the cipher works. Encryption. [(X +Key) + (X + Plaintext)] (Mod N) = a residue >=0 Ciphertext = residue - N Decryption. Plaintext (as messagetext) = Ciphertext +2N Key 2X = denary representation in ASCII. The decryption algorithm is an equation in four unknowns i.e. the Plaintext, the Key, the modulus N and X. Key, N, and X must be supplied so as to evaluate the denary value in ASCII of the Plaintext as messagetext. Recapping. X = 14313. There are 95^2 or 9025 combinations of Key and Plaintext. N = 14250. In passing, the key space is 9025 x 14250 = 128606250 (no significance to this statistic) The Worked Example. Lets say that I want to encrypt the letter capital P which has denary representation of 80 in my plaintext domain of the ASCII printable subset. Lets say also that the key that was called by the program is the character @ which has denary representation 64 in ASCII also. The modulus N that was called from the array of Ns is somewhere between 14440 and 28690 (previous work), lets say it is 19653 (a pure guess is ok). Then, Encryption. [(14313 + 64) + (14313 +80)] (Mod 19653) = 9117 Ciphertext = -10536 Decryption. Plaintext = -10536 + 2 x 19653 64 2 x 14313 = 80 (as the denary representation) The denary representation 80 translates back as capital P in ASCII as you would expect. The reader is asked to test as many variations of this encryption example as you wish and let me know if you find anything wrong with it. This is a very efficient cipher and much more so than the vector ciphers that are also on the table. The vector ciphers are very elegant although I must admit the ciphertext expansion is pretty great. I take the view that it is unbreakable security of information at any cost the cost is not important at national level anyway. In practice the ciphertext is always negative so I just treat it as a positive integer while it is in electronic email transit and multiply it by (1) on arrival. There are five versions of this cipher up and running they are available as a download complete with compiler and PDF from my website http://www.scalarcryptography.co.uk The cipher encryption/decrytpion rate is very high on my home computer should be very fast in a larger commercial mini computer I think .. cheers - adacrypt
From: adacrypt on 19 Jul 2010 11:25 On Jul 19, 10:46 am, Sebastian <s.gesem...(a)gmail.com> wrote: > On 19 Jul., 10:04, adacrypt wrote: > > > [...] > > On your website you state that you read lots of books on cryptography > but liked Simon Sigh's "The Code Book" the best. What other books did > you read exactly ? > > As for public key cryptography, it seems Simon Sigh's book at least > introduces the concept -- judging by the table of contents. Did you > forget about that ? Maybe you should re-read that chapter... > > In one of your PDFs you state that we need perfect secrecy. Your > reasoning is that someone might discover new algorithms or build new > machines that handle a full brute-force search in a key space of 256 > bits in a couple of minutes. Well, as for "algorithms": Smart people > constantly try to break ciphers. Ciphers are often designed with a > "security margin" to account for "unexpected attacks". The advances > there are rather slow and even if a cipher is broken that doesn't > imply that the attack has any use in practice (yet). But it is a > warning and a good enough reason to think about new designs. As for > the machines cracking ciphers, I'm no physics expert but I'm aware of > physical arguments involving real lower energy limits (seehttp://en.wikipedia.org/wiki/Brute_force_attack) for just > representing the sequence of keys in a brute-force attack in memory > (without actually doing anything else). These energy levels are so > high with key sizes of 128 bits or above that there is simply no way > for an attacker to come up with that. Double your key size (256 bits) > and you get a security margin that is *way* above high enough. So, I > think your assessment of the security situation is far too > pessimistic. If I have to choose between ciphers that don't provide > perfect secrecy (by Shannon's definition) but have a high security > margin and a large enough key space and another cipher that provides > perfect secrecy, I'll go with the former. Simply because we already > know that perfect secrecy implies keys that are as long as the > messages and must not be reused. For almost every application this is > unacceptable. > > Ok, ignoring that perfect secrecy ciphers are painful to use correctly > due to the large one-time keys, what exactly is it that makes your > approach any better than the plain one-time pad algorithm? I don't see > any benefits. Only disadvantages. For example, it looks like your > ciphertexts are much larger (take up more memory) than the plaintexts. > Correct me if I'm wrong. So, what's the deal here? Why bother with a > convoluted algorithm that is not any better than the plain OTP ? > > Cheers! > SG Hi Sebastion, >So, what's the deal here? Why bother with a >convoluted algorithm that is not any better than the plain OTP ? Your'e covering far to much ground here with your general philosophy for me to try and counter whatyou say by post - got to be some other time - i don't wish to be evasive but that's the way it is - regards - adacrypt
From: Mok-Kong Shen on 19 Jul 2010 13:48
adacrypt wrote: > Hi,Worked Example - Using my methods: > Let�s say I want to set up a crypto scheme that will enable any > message length from one to 14250 characters long (as an arbitrary > figure), to be encrypted. > I will need two key sets of that same length also. > There are two random key sets required i.e. the keypad formed from > multiples of the ASCII subset and the set of moduli being called �N�s > > Then minimum value that X may take = 14250 + 63 = 14313 in the formula > that follows. > i.e. X is initialised at 14313. > > The set of N�s as moduli. > �N� belongs in the range (X +127) to 2(X+32) i.e. 14440 to 28690. > Checking, 28690 � 14440 = 14250 => the keyset of N�s is 14250 (ok) [snip] Sorry that I am not smart enough and have to capture your stuff step by step. So I'll in this post first try to understand only the first part of your post as above. Are the following points correct? (1) The partners have agreed on two secret character strings (let's name them S1 and S2) each of length 14250. (2) One may repeatedly use S1 and S2, e.g. one could use them to send 10000 messages of 10000 characters. (3) X, chosen above satisfying the criterion, is fixed, i.e. constant for 'all' messages to be sent in future. Questions: Does "set of N's" imply that there are a number of different values of N that will be used (the range of N has been given above)? How many N's will be needed for a message of, say, 10000 characters? How are they chosen? The partners have certainly to agree on their values. How is that done? After learning your explanations I'll proceed to pose questions on the part of your post that I have snipped for the present. Thanks. M. K. Shen > > The set of keys being called �Key�. > This key set is created ad hoc at runtime by the computer reading in > the message for encryption and then calculating the number of > multiples of the 95 elements of the ASCII printable subset that will > be needed to provide an adequate key-length (this may require some > padding of the message to bring the two to be equal in length. > > Both of these key sets are read into the empty, waiting to be filled, > arrays of the program software. At runtime the program will call the > elements of each key array in sequential order as required, the arrays > are volatile and will empty themselves at the end of the program run. > The arrays are scrambled and sliced according to parameters that Alice > alone decides. Bob follows her instructions to stay in sync. > > X as a key. > In theory X is a key also but no great reliance of crypto strength is > ascribed to it by me because of it being a constant but it does count > as a stumbling block to some degree to an adversary. > > Note: > This version of the cipher plans ahead as a general modus operandi > that permits many message lengths. It could also be arranged that > each message length is calculated at run time and dedicated keys of > the bare key-length are used - this as an added foil to > cryptanalysis. > > How the cipher works. > > Encryption. > [(X +Key) + (X + Plaintext)] (Mod N) = a residue>=0 > Ciphertext = residue - N > > Decryption. > Plaintext (as messagetext) = Ciphertext +2N � Key � 2X = denary > representation in ASCII. > > The decryption algorithm is an equation in four unknowns i.e. the > Plaintext, the Key, the modulus �N� and X. Key, N, and X must be > supplied so as to evaluate the denary value in ASCII of the Plaintext > as messagetext. > > Recapping. > > X = 14313. > There are 95^2 or 9025 combinations of Key and Plaintext. > N = 14250. > In passing, the key space is 9025 x 14250 = 128606250 (no significance > to this statistic) > > The Worked Example. > Lets say that I want to encrypt the letter capital P which has denary > representation of 80 in my plaintext domain of the ASCII printable > subset. > > Lets say also that the key that was called by the program is the > character @ which has denary representation 64 in ASCII also. > > The modulus N that was called from the array of N�s is somewhere > between 14440 and 28690 (previous work), lets say it is 19653 (a pure > guess is ok). > > Then, > Encryption. > [(14313 + 64) + (14313 +80)] (Mod 19653) = 9117 > Ciphertext = -10536 > > Decryption. > Plaintext = -10536 + 2 x 19653 � 64 � 2 x 14313 = 80 (as the denary > representation) > > The denary representation 80 translates back as capital �P� in ASCII > as you would expect. > The reader is asked to test as many variations of this encryption > example as you wish and let me know if you find anything wrong with > it. > > This is a very efficient cipher and much more so than the vector > ciphers that are also on the table. The vector ciphers are very > elegant although I must admit the ciphertext expansion is pretty > great. I take the view that it is unbreakable security of information > at any cost � the cost is not important at national level anyway. > > In practice the ciphertext is always negative so I just treat it as a > positive integer while it is in electronic email transit and multiply > it by (�1) on arrival. > > There are five versions of this cipher up and running � they are > available as a download complete with compiler and PDF from my website > http://www.scalarcryptography.co.uk The cipher encryption/decrytpion > rate is very high on my home computer � should be very fast in a > larger commercial mini computer I think > . � cheers - adacrypt > > |