[131964] in cryptography@c2.net mail archive
Re: Decimal encryption
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Fri Aug 29 13:26:15 2008
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ekr@networkresonance.com, pgut001@cs.auckland.ac.nz
Cc: cryptography@metzdowd.com, pg@futureware.at
In-Reply-To: <20080828054020.9DFA1562DE5@kilo.rtfm.com>
Date: Fri, 29 Aug 2008 20:25:36 +1200
Eric Rescorla <ekr@networkresonance.com> writes:
>There's noting inherently wrong with this mechanism, but like all stream
>ciphers, it can't be used if you want to encrypt multiple independent values,
>e.g., credit cards in a database--without a randomizer (which implies
>expansion) you have the usual two-time pad problems. A B-R style block cipher
>can, albeit with lookup table issues.
Sure, thus the thread on sci.crypt about all the little situation-specific
tweaks you can apply. In this case it was being used to encrypt ongoing ASCII
streams (computer terminal traffic, SMS, and other stuff) so there weren't
multiple independent values (the terminal-traffic one was particularly
interesting because it needed to encrypt discontinuous ranges so that control
characters went through without encryption). As you say, if you're processing
independent values you'd need to tweak it somehow, for example by using a
public value like the account number as an IV if you're using this to encrypt
the credit card number stored next to the account number (with standard
caveats about IV reuse, birthday attacks, and so on, pedants please assume a
two-page enumeration of requirements here :-).
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
