Encrypting odd sized buffers
in [Cryptography]
|
From: Ross MacGregor on 24 Jun 2010 03:01 You guys are awesome, thanks for all the help! unruh wrote: > split input into input1 input2 each 54 bits long (Actually padding out > to 56 bits would probably be far more convenient)(however you want to do so) > > Define a round as > inputs are c1, c2 > d1=Tmd5(key1+c1)^c2 > d2=Tmd5(key2+d1)^c1 > c1=d1 > c2=d2 > repeat N times. Thank for algorithm. I coded this up today and it works! I used sha2 instead of md5. I'm curious why the algorithm is written like this and not more like Maaartin's and Tran Ngoc Duong's algorithm below. It seems better expressed that way. Is it done like this to only use two keys? When they say that 5 rounds should be enough to sufficently scramble the output, do they me 5 iterations of the above algorithm or the ones below? Maaartin wrote: > for (int i=0; i<6; ++i) { > x ^= truncateTo54bits(hash(concat(y, key[i]))); > swap(x, y); > } Tran Ngoc Duong wrote: > for(i = 0; i<53; i++) > { > t = x0+Z[i]+i; > x1 ^= ROTL18(U54(t*(2*t+1))); > swap x0, x1; > }
From: Ross MacGregor on 24 Jun 2010 03:11 Tran Ngoc Duong wrote: > Here is a 108-bit block cipher that I've just crafted specifically for > your need. It is a 54-round Feistel structure and > it uses the function f(x) = (x*(2*x+1)) <<< 18 (over 54-bit numbers). Thanks for all the work on this, I really appreciate it! I will probably go with an established hash function for this as performance should not be an issue. Why did you suggest 54 rounds?
From: Paul Rubin on 24 Jun 2010 03:16 Ross MacGregor <ross__macgregor(a)hotmail.com> writes: > When they say that 5 rounds should be enough to sufficently scramble > the output, do they me 5 iterations of the above algorithm or the ones > below? Each "round" means one computation of the hash function/xor. So in the first version, each pass through the loop did two "rounds". Be careful about the inputs. Maybe you can use a 32 bit counter (for your uniqueness guarantee) and 76 random bits. But the randomness of those random bits then becomes rather crucial, and generating good randomness in an autonomous embedded device (if that's what you're doing) isn't trivial.
From: Mok-Kong Shen on 24 Jun 2010 03:42 Ross MacGregor wrote: > > This code will be audited by third-party to ensure it passes the > regulations and requirements. Depending on who these people are and what > kind of day they are having we could get rejected because because the > PRNG does not guarantee unique cycle of numbers. I don't yet understand what kind of applications do you have. But never mind. In another post of yours that I have just answered, you seemed to confirm that security isn't an issue for you. Note that the permutation polynomials I mentioned are in fact used as PRNGs, including the very popular linear one: f(x)=a*x+b mod 2^n. If the criteria about the cofficients, which are trivial to be met in practice, are satisfied, then the PRNG (with a polynomial of any order you prefer) does guarantee unique cycle of numbers that you require. M. K. Shen
From: Mok-Kong Shen on 24 Jun 2010 04:13
Ross MacGregor wrote: > > ........... Depending on who these people are and what > kind of day they are having we could get rejected because because the > PRNG does not guarantee unique cycle of numbers. Just a question out of curiosity: What's the problem of using the simplest PRNG f(x)=a*x+b mod 2^108 (a odd) in your application? (The inverse of a can be simply computed once for all for later efficient inversion of the mapping.) There appears to be nothing against employing that simplest scheme from what you posted todate. M. K. Shen |