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: J.D. on 22 Apr 2010 22:30
On Apr 22, 3: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.
>
> 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.

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). Hence, an
attacker could conduct a sort of traffic analysis -- determining when
you are talking about the same accounts. If I read your question
right, you seem to want this property (i.e. to allow parties who don't
have the key to see when you are talking about the same account id).
If you do indeed want this property then you should be aware it might
allow attackers to deduce the ids (sort of like how using code words
instead of actual names is not particularly secure, because given
enough contextual clues an attacker might be able to guess what the
codes mean). If you are fine with that possibility then using Triple
DES in ECB is the way to go.

But if you don't want to allow that, there are several ways to prevent
such a breach, even if you want to stick with a 64 bit block cipher
like Triple DES. For example, you could simply use a new and randomly
generated set of keys every time you send an encrypted account id.
This however is inefficient -- you would need a secure key exchange
protocol, and if you can securely send 112 or 168 bits worth of secret
key then you might as well use that channel to securely send the 64
bit account id and skip all this tomfoolery with a block cipher.
Another, better option (especially if you don't want to change keys
very often) would be to use Initialization Vectors (IVs): i.e. during
set-up with the other party (when you first exchange your secret key),
agree on a means to generate a succession of (preferably pseudo
random) IVs of 64 bits each, and then each time you send an account id
you xor the account id with the next IV and encrypt the result with
Triple DES (or Blowfish or Skipjack or RC5 or Khazad or whatever --
Triple DES is the conservative choice). The other party can read the
account id by simply decrypting and then xoring the result with the
same IV.
First  |  Prev  | 
Pages: 1 2
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!