RE: Encrypted Communications and Predictable Communications?

If you have known ciphertext and known plaintext, you can run
every possible key and be able to tell when you get the right one.

You want to be sure your key is long enough that this is infeasible.
Note this is how DES was broken; the number of tests per second
that can be run is a function of technology.

There are more sophisticated attacks which might use known plaintext
so the above mentioned attack is kind of a best case for the cipher.

If you have no known plaintext, it can be impossible to know if
you have successfully decrypted a message. Consider a onetime pad.
In that case, the ciphertext can decrypt into any plaintext at
all, so there is no test to tell which one is right unless you
know some plaintext.

-----Original Message-----
From: Jonathan Leffler [mailto:[email protected]]
Sent: Tuesday, August 03, 2004 1:26 PM
To: [email protected]
Subject: Encrypted Communications and Predictable Communications?


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.


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************