home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: sci.crypt
- Path: 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
-
- 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
-