From: Marc VanHeyningen <mvanheyn@whale.cs.indiana.edu>
Subject: RIPEM Frequently Noted Vulnerabilities (and defenses)
Followup-To: alt.security.ripem
Summary: A monthly description of some potential attacks on RIPEM
Originator: mvanheyn@silver.ucs.indiana.edu
Supersedes: <1993Jan4.223743.452@news.cs.indiana.edu>
Organization: Computer Science Dept, Indiana University
Distribution: na
Date: Tue, 5 Jan 1993 16:17:23 GMT
Expires: Mon, 15 Feb 1993 00:00:00 GMT

Archive-name: ripem/attacks
Last-update: Mon, 04 Jan 93 22:07:58 -0500


SOME POSSIBLE ATTACKS ON RIPEM

This is a living list of potential weaknesses to keep your eyes open for
when using RIPEM for secure electronic mail.  It does not go into great
detail, and is almost certainly not exhaustive.  It is maintained by
Marc VanHeyningen <mvanheyn@whale.cs.indiana.edu>.

CRYPTANALYSIS ATTACKS

- Breaking RSA would allow an attacker to find out your private key,
  in which case he could read any mail encrypted to you and sign
  messages with your private key.

  RSA is generally believed to be resistant to all standard
  cryptanalytic techniques.  Even a standard key (about 516 bits with
  RIPEM) is long enough to render this impractical, barring a
  significant investment in hardware.

- Breaking DES would allow an attacker to read any given message,
  since the message itself is encrypted with DES.  It would not allow
  an attacker to claim to be you.

  DES has only 56 bits in its key, and thus could conceivably be
  compromised by brute force with sufficient hardware, but few agencies
  have such money to devote to simply read one message.  Since each
  message has a different DES key, the work for each message would
  remain high.

KEY MANAGEMENT ATTACKS

- Stealing your private key would allow the same benefits as breaking
  RSA.  To safeguard it, it is encrypted with a DES key which is derived
  from a passphrase you type in.  However, if an attacker can get a copy
  of your private keyfile and your passphrase (by snooping network
  packets, tapping lines, or whatever) he could break the whole scheme.

  The main risk is that of transferring either the passphrase or the
  private key file across an untrusted link.  So don't do that.  Run 
  RIPEM on a trusted machine, preferably one sitting right in front of
  you.  Ideally, your own machine in your own home (or maybe office)
  which nobody else has physical access to.

- Fooling you into accepting a bogus public key for someone else could 
  allow an opponent to deceive you into sending secret messages to him
  rather than to the real recipient.  If the enemy can fool your
  intended recipient as well, he could re-encrypt the messages with
  the other bogus public key and pass them along.

  It is important to get the proper public keys of other people.
  The most common mechanism for this is finger; assuming the opponent
  has not compromised routers or daemons or such, finger can be 
  given a fair amount of trust.  The strongest method of key
  authentication is to exchange keys in person; however, this is
  not always practical.  Having other people "vouch for you" by
  signing a statement containing your key is possible, although 
  RIPEM doesn't have features for doing this as automatically as
  does PGP.


PLAYBACK ATTACKS

- Even if an opponent cannot break the cryptography, an opponent could
  still cause difficulties.  For example, suppose you send a message
  with MIC-ONLY to Alice which says "OK, let's do that." Your opponent
  intercepts it, and now resends it to Bob, who now has a message which
  is authenticated as from you telling him to do that.  Of course, he
  may interpret it in an entirely different context.  Or your opponent
  could transmit the same message to the same recipient much later,
  figuring it would be seen differently at a later time.  Or the
  opponent could change the Originator-Name: to himself, register 
  your public key as his, and send a message hoping the recipient
  will send return mail indicating (perhaps even quoting!) the unknown
  message.

  To defeat playback attacks, the plaintext of each message should 
  include some indication of the sender and recipient, and a unique
  identifier (typically the date).  A good front-end script for RIPEM
  should do this automatically (IMHO).  As a recipient, you should be
  sure that the Originator-Name: header and the sender indicated within
  the plaintext are the same, that you really are a recipient, and that
  the message is not an old one.  Some this also can and should be
  automated.


STUPID ATTACKS

- Leaving unencrypted files around for someone to find them

- Decrypting on a remote machine when the link between you and it is
  not trusted

- And on and on...
-- 
Marc VanHeyningen    mvanheyn@indiana.edu     MIME accepted
Computer Science    
Indiana University    The cultural elite are neither!
Generic Grad Student  (well, certainly not the latter, anyway...)