Encrypting odd sized buffers
in [Cryptography]
|
From: unruh on 23 Jun 2010 05:22 On 2010-06-23, Kristian Gj?steen <kristiag+news(a)math.ntnu.no> wrote: > Ross MacGregor <ross__macgregor(a)hotmail.com> wrote: >>I am a senior software >>developer but without much cryptographic experience. >> >>Paul Rubin wrote: >>>[...] >>> There was also the Hasty Pudding Cipher, a variable-sized block cipher >>> from the original AES competition. >>Thanks, I am looking at this as an option. > > Use Hasty Pudding. I don't think Luby-Rackoff is a fail-safe > construction. If a system contains a Luby-Rackoff cipher cobbled > together by a non-cryptography, that system should fail at the first > security review. All he wants is a raondom number generator. > > Alternatively, use AES(k,.) truncated to 108 bits (or truncated SHA-2(k >|| .) or ...), which will most likely be a permutation as long as you > don't evaluate it at too many points. AES truncated is NOT guarenteed to be unique. There is no advantage of this to using say MD5(key+consecutive number) or urand collecting 14 bytes. >
From: Kristian Gj�steen on 23 Jun 2010 05:59 Maaartin <grajcar1(a)seznam.cz> wrote: >On Jun 23, 10:20�am, Kristian Gj steen <kristiag+n...(a)math.ntnu.no> >wrote: >> Use Hasty Pudding. �I don't think Luby-Rackoff is a fail-safe >> construction. �If a system contains a Luby-Rackoff cipher cobbled >> together by a non-cryptography, that system should fail at the first >> security review. > >Why? The following is orders of magnitude simpler than HPC, so how can >be the error-rate higher? > >for (int i=0; i<6; ++i) { >x ^= truncateTo54bits(hash(concat(y, key[i]))); >swap(x, y); >} I'm not talking about implementation, I'm talking about design. If you are a non-cryptographer doing a security review of a design, what would you least like to see: - A non-cryptographer uses a reasonably reputable block cipher to do something. - A non-cryptographer uses an obscure crypto-technique recommended by random strangers on the internet to produce a home-brew cipher to do something. -- kg
From: Francois Grieu on 23 Jun 2010 06:18 On 23/06/2010 02:40, Maaartin awrote: > On Jun 22, 8:29 pm, Paul Rubin wrote: >> Francois Grieu <fgrieu(a)gmail.com> writes: >>> I'm thinking a bit *more* than 4 rounds when we are talking very small >>> blocks, because Luby-Rackoff leaves some permutations more likely than >>> others, I think appreciably for 4 rounds and up to 4 bits. I welcome a >>> quantitative evaluation of the number of rounds necessary for this >>> effect to fade away beyond observability. > >> There have been a couple threads about this in the past. I remember >> doing some experiments on blocks up to 8 bits or something like that. > > How can it be done? With n bits, there are (2**n) ** (2**n) > functions, which for n=4 equals 2**64, and the number of permutation > is too high as well. I see no way how to find out if you can get them > all using e.g. 4 rounds plus a modification as I or Francois Grieu > proposed. I don't even know how to do any useful statistics. For n=3 > it's easy to evaluate all possibilities, but for n=4 you need > something less trivial. For a n-bit block balanced r-round Luby-Rackoff construct, we have r hash functions with 2**(n/2) inputs and n/2 bits output, thus 2**((2**(n/2))*(n/2)*r) such constructs. For n=4, m=4 I get 2**32, not 2**64. That's manageable. I think I once did an exploration of how these map to the n!/2 = 12 even permutations. Francois Grieu
From: Mok-Kong Shen on 23 Jun 2010 06:24 Mok-Kong Shen wrote: > Ross MacGregor wrote: >> >> Mok-Kong Shen wrote: >>> Ross MacGregor wrote: >>> What do you exactly mean by 'byte sized buffers' above? Do you simply >>> want a more or less good bijective mapping that transforms 108 bits to >>> 108 bits >> Yes, this is all I am looking for. I was just trying to say that all the >> block cyphers I've seen use fixed sized buffers. > > I realize that my question was not absolutely unambiguous. Could you > concretely state the properties you expect of such a mapping? [Addendum] I meant that the wordings of your previous posts leave open a (IMHO at least 'minutely') possible interpretation that security might not be a requirement for you and what you seek was only randomness, in which case the solution would have been rather simple. M. K. Shen
From: Francois Grieu on 23 Jun 2010 11:04
[reposted with correction] On 23/06/2010 02:40, Maaartin awrote: > On Jun 22, 8:29 pm, Paul Rubin wrote: >> Francois Grieu <fgrieu(a)gmail.com> writes: >>> I'm thinking a bit *more* than 4 rounds when we are talking very small >>> blocks, because Luby-Rackoff leaves some permutations more likely than >>> others, I think appreciably for 4 rounds and up to 4 bits. I welcome a >>> quantitative evaluation of the number of rounds necessary for this >>> effect to fade away beyond observability. > >> There have been a couple threads about this in the past. I remember >> doing some experiments on blocks up to 8 bits or something like that. > > How can it be done? With n bits, there are (2**n) ** (2**n) > functions, which for n=4 equals 2**64, and the number of permutation > is too high as well. I see no way how to find out if you can get them > all using e.g. 4 rounds plus a modification as I or Francois Grieu > proposed. I don't even know how to do any useful statistics. For n=3 > it's easy to evaluate all possibilities, but for n=4 you need > something less trivial. I check and recheck, but for a n-bit block, balanced, r-round Luby-Rackoff construct, I find there are r Pseudo-Random Functions each with 2**(n/2) inputs values and n/2 bits output, thus 2**((2**(n/2))*(n/2)*r) choices of such PRF. For n=4, m=4 I get 2**32, not 2**64 as Maaartin. That would be manageable. Or maybe I'm wrong. There are (2**n)!/2 even permutations of n_bit words, that's 10461394944000 for n=4; IF my above count is correct [I made so many mistakes in this thread that it is a big if] less than 1 in 2000 permutation can be reached, and this figure quickly worsens when n grows. Francois Grieu |