Re: des_ssh1_setiv not setting the IV ?

[Dan Kaminsky]

> I'll be the first to admit that I don't know the OpenSSH architecture,
> but this appears to be an oversight that would go un-noticed until
> someone wanted a non-zero IV .. how often does that happen? Is this a
> known issue, for compatibility?
>
> Have I missed something else entirely? :)

Seth--

   [The short version: fixed initialization vector is not a threat,
because the entire symmetric key changes with each session]

   I looked into this a bit, and this behavior isn't a bug, rather it's
part of the explicit design of SSH1.  According to the SSH1 spec
(http://www.snailbook.com/docs/protocol-1.5.txt):

   SSH_CIPHER_DES
        The key is taken from the first 8 bytes of the session key.  The
        least significant bit of each byte is ignored.  This results in
        56 bits of key data.  DES [DES] is used in CBC mode.  The iv
        (initialization vector) is initialized to all zeroes.

   SSH_CIPHER_3DES
        The variant of triple-DES used here works as follows: there are
        three independent DES-CBC ciphers, with independent initializa-
        tion vectors.  The data (the whole encrypted data stream) is
        first encrypted with the first cipher, then decrypted with the
        second cipher, and finally encrypted with the third cipher.  All
        The key for the first cipher is taken from the first 8 bytes of
        the session key; the key for the next cipher from the next 8
        bytes, and the key for the third cipher from the following 8
        bytes.  All three initialization vectors are initialized to
        zero.

   One of the major goals of a cryptosystem is to prevent one-to-one
relationships between an occurance of plaintext(abc) and an occurance of
ciphertext(xyz,pdq,#21,etc.)  When the same symmetric key is used twice,
there is a risk of that one to one relationship.  CBC, or Cipher Block
Chaining mode makes each future block dependent upon the contents of a
previous block -- so the simple variability of past data prevents future
data from encrypting identically.  However, if there *is* no variable past
data, the one to one still exists.  Initialization Vectors are
essentially "imagined past data" that is publically exchanged so that
identical first blocks(and all blocks that follow, until sessions start to
diverge) won't have to be identical.

   What's critical, though, is that SSHv1 *doesn't* use identical
symmetric keys from one session to the next; rather, it uses a long term
public key to authenticate a short term public key, then that short term
public key to transfer the symmetric key actually used to transfer the
data for that session.  Because of this, no initialization vector needs to
be exchanged--they're already exchanging unique keys.  You can't do that
safely with a purely symmetric cryptosystem, however, so most symmetric
systems have provisions for initialization vectors.

   I do admit that I was slightly concerned when I read that SSH was
fixing its initialization vectors, but unless I'm mistaken(and that's
possible!), the manner in which SSH uses symmetric algorithms like 3DES
and Blowfish entirely sidesteps the security risks that initialization
vectors were intended to address.

Yours Truly,

   Dan Kaminsky
   DoxPara Research
   http://www.doxpara.com

P.S. Yes, this is the former dankamin at cisco.com, and it's good to be
back :-)