🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.crypt
Article #1129

Re: Deterring plaintext attacks

#1129
From: Christopher Browne
Date: Thu, 05 Nov 1992 23:20
65 lines
3506 bytes
In article <1992Nov5.154602.28033@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
>In article <1992Nov5.000740.1755@qiclab.scn.rain.com>, leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
>> gilchr@ee.ualberta.ca (Andrew Gilchrist) writes:
>> 
>> >What are theoretic ways to deter a plaintext attack?
>> 
>> >i.e. The opponent is given two ciphertext messages, the plaintext of
>> >the first message, and the encryption method.
>> 
>> 
>> >Now, obviously the longest key in the world will not help.
>> 
>> >How does one protect the key, so that it can be reused.
>> 
>> You *can't*.
>That's not true at all.  Rather, it's not true for most types of
>cryptosystems.  Consider DES -- as far as the non-classified world
>knows, it's immune to known-plaintext attacks.  Even if you run DES
>in output feedback mode, generating an XOR stream similar to what
>the original poster asked about, the *key* is the 56 bits you fed
>into the DES engine, not the output from DES acting as a cryptographically
>strong random number generator.

(a) If you add some "salt" to the plaintext, it helps.  I.e. - adding some
"really" random material to the plaintext can be helpful.  This is the
sort of thing that's done with UNIX passwords - DES is used to encrypt
a combination of (a) zeros, and (b) a random bitstring.  This means that
even if you use the same password on different accounts, the entry in
/etc/passwd won't be the same on the different accounts.

Thus, here the issue isn't "protecting the key", the issue is "protecting 
the plaintext."

(b) It looks to me like the plaintext issue relates to making sure that
the encryption is powerful enough.

If your encryption can keep a compressed binary file from being decrypted, 
that's probably no big deal.  Since it might be difficult to make sense
of the FINAL product, it's probably easy to make it unbreakable.

The REAL test is if you can keep secret a set of text that should be
``easy to decrypt,'' or at least, easier than average.  If the cipher
can defy analysis on easy text (better still, KNOWN text), then it's
probably quite safe.

I.E.: The BEST(/worst) case scenario would be as follows:
Assume:
(a) I have a plaintext copy of message M.
(b) I have an encrypted copy of message M, E(K,M).
(c) I don't know the key, K

If the cipher scheme is REALLY good, I won't be able to determine the
key, K, even though I have M, E(K,M) and information on the encryption
function E.

This, of course, is the point of RSA - even given messages and public
keys, it's very hard to determine the private key.

And DES seems to be pretty resistant to attack even of this type.

-- 
Christopher Browne                |     PGP 2.0 key available
cbbrowne@csi.uottawa.ca           |===================================
University of Ottawa              |  The Personal Computer:  Colt 45
Master of System Science Program  |  of the Information Frontier
Technical Details
Message-ID: <1992Nov5.232009.18872@csi.uottawa.ca>
Path: arc1-ca.pugleaf.net!sparky!uunet!utcsri!torn!nott!cunews!csi.uottawa.ca!news
References: <gilchr.720707527@ee.ualberta.ca> <1992Nov5.000740.1755@qiclab.scn.rain.com> <1992Nov5.154602.28033@ulysses.att.com>

Show Full Headers
Complete Article Headers
Newsgroups: sci.crypt
Path: arc1-ca.pugleaf.net!sparky!uunet!utcsri!torn!nott!cunews!csi.uottawa.ca!news
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: Deterring plaintext attacks
Message-ID: <1992Nov5.232009.18872@csi.uottawa.ca>
Sender: news@csi.uottawa.ca
Nntp-Posting-Host: prgw
Organization: Dept. of Computer Science, University of Ottawa
References: <gilchr.720707527@ee.ualberta.ca> <1992Nov5.000740.1755@qiclab.scn.rain.com> <1992Nov5.154602.28033@ulysses.att.com>
Date: Thu, 5 Nov 92 23:20:09 GMT
Lines: 65