Re: Encrypted Communications and Predictable Communications?

Roughly, no.  If the attack you describe (the known plaintext, chosen
plaintext, or adaptive-chosen plaintext attacks) work, the cipher is
considered broken by modern academic cryptographers.  By the attack
working, I mean substantially reduce the time it takes to search for
the key.

Steve Bellovin did a great paper on this issue with IPSec, Probable
Plaintext Cryptanalysis of the IP Security Protocols,
http://www.research.att.com/~smb/papers/probtxt.pdf

Adam

On Tue, Aug 03, 2004 at 10:26:14AM -0700, Jonathan Leffler wrote:
| My understanding of cryptography in general is that it is easier to 
| determine the key for an encrypted message if you have (some) known plain 
| text that the encrypted message will probably contain.  This might provide 
| you with the leverage to get the rest of the data - the unknown part of 
| the message.
| 
| With program-to-program message streams encrypted using ... choose your 
| system - OpenSSL or TLS or ... where the programs have a known clear text 
| protocol, and (obviously) the encoding of the messages is known 
| (Kerchoff's Principle: the security is only in the keys), does the known 
| text provide sufficient leverage to allow a session to be cracked offline 
| (or, more precisely, how much known plain text would be necessary to 
| provide that leverage)?
| 
| Concrete situation: consider a database system, with a client application 
| on one machine and a database server on another.  In general, clients can 
| connect using either encrypted or unencrypted communications, so it 
| reasonable to assume that the intruder can analyze the unencrypted message 
| exchanges and understand the structure of the messages sent back and 
| forth.  When the client connects and sets up an encrypted channel with the 
| server, it then communicates using a standard protocol with well known 
| messages (and MAC to validate the messages).  For example, there's a 
| handshake double-byte at the end of each message (0x000C) in either 
| direction of the unencrypted protocol; the initial message contains other 
| predictable information; other messages contain predictable content - 
| particularly if you have access to the application itself; many messages 
| contain SQL statements, which are themselves stuffed full of easily 
| predictable text; and many of the messages are short, barely more than a 
| 4-byte command sequence and a 2-byte handshake.  Of course, the database 
| sessions are often protracted - many messages are exchanged using the same 
| key.  Database sessions are inherently stateful, unlike simple HTTP or 
| HTTPS exchanges.
| 
| Question: How much does the predictability of such message exchanges 
| degrade the security of an encryption system?  Can anybody point to any 
| literature that analyzes this issue?
| 
| Should the encryption system take steps to ensure that the encrypted data 
| contains random information to pad out messages to at least the minimum 
| block size for the encryption algorithm?  Do systems like OpenSSL do that 
| anyway?
| 
| --
| Jonathan Leffler ([email protected])
| STSM, Informix Database Engineering, IBM Data Management
| 4100 Bohannon Drive, Menlo Park, CA 94025
| Tel: +1 650-926-6921   Tie-Line: 630-6921
|       "I don't suffer from insanity; I enjoy every minute of it!"
| 
| PS: I am subscribed to the digest; I won't see responses until the digest 
| is sent unless you explicitly Cc me.