unique pemutation using 3DES
in [Cryptography]
|
Prev: entropy and the Yarrow PRNG for key generation
Next: Prime Number Sums reveal both a 2D and 3D pattern when stepped by the golden ratio logarithm!
From: marvind434 on 22 Apr 2010 15:25 Hi, I am working on a problem where we have to share account ids with another party. Account ids in this problem are 64 bit numeric quantities. We do not want to reveal the id but want to preserve 1:1 mapping to allow 3rd party to correlate using the transformed id on some event stream. The number of ids is huge and grows every day. Furthermore the mapped quantity should be 64 bit numeric as well due to limitations on 3rd party site. I thought may be I could use encrypt account id using 3DES in ECB mode and just return the final block as 64 bit numeric quantity. I have read that the block ciphers can be considered to be pseudo random permutations and want to know if my approach is correct. Normally if there was no constraint on output size, we would just return a MAC and live with low chance of collision. I also think XOR'ing each account id with a fixed random number that we keep secret is not a good idea because it will leak relationship between account numbers. I am open to other suggestions as well but I want to avoid storing any per account id meta data. Thanks.
From: Mok-Kong Shen on 22 Apr 2010 16:08 marvind434 wrote: > I am working on a problem where we have to share account ids with > another party. Account ids in this problem are 64 bit numeric > quantities. We do not want to reveal the id but want to preserve 1:1 > mapping to allow 3rd party to correlate using the transformed id on > some event stream. The number of ids is huge and grows every day. > > Furthermore the mapped quantity should be 64 bit numeric as well due > to limitations on 3rd party site. I thought may be I could use encrypt > account id using 3DES in ECB mode and just return the final block as > 64 bit numeric quantity. > > I have read that the block ciphers can be considered to be pseudo > random permutations and want to know if my approach is correct. IMHO this is certainly correct, the 1:1 is guaranteed by the fact that decryption inverses encryption. M. K. Shen
From: Maaartin on 23 Apr 2010 09:34 On Apr 23, 4:30 am, "J.D." <degolyer...(a)yahoo.com> wrote: > Well, the trouble with using straight forwards ECB to conceal the > account ids is that the same id will always produce the same > ciphertext (assuming you use the same key(s) each time). IMHO, the OP wants to use ECB only for the id transformation. His reason is to protect the ids from the party he communicates with while maintaining a 1:1 correspondence. For the communicating itself he can use another encryption, which needn't and shouldn't work in ECB mode.
From: J.D. on 23 Apr 2010 11:49 On Apr 23, 9:34 am, Maaartin <grajc...(a)seznam.cz> wrote: > On Apr 23, 4:30 am, "J.D." <degolyer...(a)yahoo.com> wrote: > > > Well, the trouble with using straight forwards ECB to conceal the > > account ids is that the same id will always produce the same > > ciphertext (assuming you use the same key(s) each time). > > IMHO, the OP wants to use ECB only for the id transformation. His > reason is to protect the ids from the party he communicates with while > maintaining a 1:1 correspondence. For the communicating itself he can > use another encryption, which needn't and shouldn't work in ECB mode. Hmm, that makes somewhat more sense. I misinterpreted his use of "3rd party" it would seem.
From: Maaartin on 22 Apr 2010 19:51
On Apr 22, 9:25 pm, marvind434 <marvind...(a)gmail.com> wrote: > Hi, > > I am working on a problem where we have to share account ids with > another party. Account ids in this problem are 64 bit numeric > quantities. We do not want to reveal the id but want to preserve 1:1 > mapping to allow 3rd party to correlate using the transformed id on > some event stream. The number of ids is huge and grows every day. > > Furthermore the mapped quantity should be 64 bit numeric as well due > to limitations on 3rd party site. I thought may be I could use encrypt > account id using 3DES in ECB mode and just return the final block as > 64 bit numeric quantity. For 1:1 mapping you definitely need a cipher. Out of the 64-bit ciphers, 3DES is AFAIK the most u8nderstood and believed to be secure. The only drawback is its speed. All well-known better ciphers uses larger blocks. > I have read that the block ciphers can be considered to be pseudo > random permutations and want to know if my approach is correct. > > Normally if there was no constraint on output size, we would just > return a MAC and live with low chance of collision. I also think > XOR'ing each account id with a fixed random number that we keep secret > is not a good idea because it will leak relationship between account > numbers. XOR is as good as doing nothing. With a single plaintext-ciphertext pair everything is known. > I am open to other suggestions as well but I want to avoid storing any > per account id meta data. If the speed is no concern, then your solution seems to be perfect (but I'm no expert here). |