Encrypting odd sized buffers
in [Cryptography]
|
From: Maaartin on 22 Jun 2010 21:25 On Jun 23, 2:40 am, Maaartin <grajc...(a)seznam.cz> wrote: > Interestingly, using Lai-Massey on 2 bits gives you only 4 functions > for any number of rounds greater than zero. This is wrong, I left the orthomorphism out. None exists, anyway.
From: Paul Rubin on 23 Jun 2010 01:22 Maaartin <grajcar1(a)seznam.cz> writes: >> 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) You're right, maybe it was only 6 bits.
From: Ross MacGregor on 23 Jun 2010 02:34 Thanks everyone for giving me the better search terms. Paul Rubin wrote: > If you don't care about speed, the simplest thing to do is chop the 108 > bits in half and make a Feistel cipher using some standard cryptographic > hash function as the round function. Sounds interesting, can anyone point me to some code to help me implement such a thing? What would be a "standard cryptographic hash function?" I am a senior software developer but without much cryptographic experience. > 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. > What is the application, if you can say? A block cipher may not be what > you want. It is to generate a unique set of random numbers, but I need to generate millions of them. I want to take advantage of the one to one mapping of input to output that a block cipher can provide. Perhaps there are specialized PRNGs for this, but I am not aware of any. >If you just want unique 108 bit numbers, you're better off > using plain random numbers and accepting the very low chance of an > collision through an accident of nature, than trying to generate them > from a sequence, and ending up with the much higher chance of using the > same seed twice through the likelier error of some human. Normally this would suffice, but for this application the algorithm must offer a strong guarantee that the sequence is unique.
From: Ross MacGregor on 23 Jun 2010 02:44 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.
From: Paul Rubin on 23 Jun 2010 02:47
Ross MacGregor <ross__macgregor(a)hotmail.com> writes: > Sounds interesting, can anyone point me to some code to help me > implement such a thing? What would be a "standard cryptographic hash > function?" I am a senior software developer but without much > cryptographic experience. Standard hash function = sha1, sha2, etc. Wikipedia's article explains Feistel ciphers: http://en.wikipedia.org/wiki/Feistel_cipher >>If you just want unique 108 bit numbers, you're better off >> using plain random numbers > Normally this would suffice, but for this application the algorithm > must offer a strong guarantee that the sequence is unique. I think random numbers give a stronger practical guarantee than generating a sequence, unless you're generating all of them in one shot. Think of ethernet MAC addresses, which are supposed to be unique, but manufacturers issue duplicates all the time, because they keep messing up initializing the sequences. If the addresses had more bits and were completely random, there'd never be collisions. Why do you want to generate millions of unique random numbers, if you don't mind my asking? How many million? Why 108 bits? If you're generating 8 million random numbers (2**23), the odds of a duplicate are approx 2**-62 or something like that. |