Re: SNMPv2 security

[Frank Kastenholz <[e-mail]>]

 > What is the reason people change their [secret] keys?
 > Why not leave the same one for indefinite time?

The more traffic in the same key that you have, the easier it is to
break the code. It is much much harder to break a key when you have
one message than when you have many messages.

Also, as you say, if my key has been compromised but I do not
know it, then only the traffic encrypted in the compromised
key is compromised.

 > Now in this XOR scheme, it doesn't matter at what point
 > in time I get your key -  but your traffic is open to
 > me from now on, both in past (pre-recorded messages)
 > and whatever you'll send in the future. Also, if
 > there's is a cryptanalytic attack on the key,
 > then these XORs make sure I'll be able to
 > exploit _all_ the traffic, rather than
 > just those messages, encrypted or
 > protected by that particular
 > key I'm trying to crack.
 > 
 > Thus - what do we save by "changing" the key in
 > such a funny way?  What kind of "attack" are we
 > twarting? Inquiring minds want to know (:-).

Ok, suppose you and I are using Kold to communicate. We wish to go
to a new key, Knew.

I send you Knew DES-encrypted with Kold. Now, for a third party to
get Knew from that transaction, they would have to know Kold.  Right?

OR

I send you Knew xored with Kold. Again, for the third party to get
Knew from the transaction they would have to know Kold. Right?

Either way, the third party must know Kold in order to extract Knew
from the data stream.

In the XOR method, you can then quite easily go back and calculate
all previous keys.  But then if DES is used to set keys, you will
have both the cipher-text (the DES-encrypted message that set Kold)
and part of the clear-text of the cipher-text (we posit that you have
Kold) so then DES becomes much less robust.  This is a tradeoff.
Transferring keys with DES would be safer, but that leads to problems
exporting goods from the US, so by using the XOR mechanism, we give
up some robustness in key transfer and make it much easier to build
easily-exportable products. Though both of these assume that Kold has
been compromised -- which is hard and where the true robustness comes
in.



P.S. There is an interesting additional bit of security in the XOR
scheme that is not in DES. In XOR, you just XOR the 16 bytes of the
key. In DES you DES-encrypt the entire packet. So, suppose I had a
machine that was capable of doing an exhaustive attack on DES (i.e.
I simply decrypt the packet using every possible key from 0 to
0xffffff...).  There are certain patterns in the packet that I can
look for. I know how the SNMP packet is encoded. I know that, e.g.,
there must be tag bytes and length bytes of a certain, knowable (or
guessable) values at a certain locations in the packet. Thus, as I do
the exhaustive DES attack, I can throw away any "provisional" key
that does not give me one of these values.

On the other hand, in XOR, you only XOR the 16 bytes of key. You do
not have any knowledge of what any of those bytes will be so you do
can not know which value is the right one.

In other words, if, after decrypting a packet with a particular DES
key the packet starts 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00... you can guess that the key is not the one that originally
encrypted the packet. If, however, you 'de-XOR' a 16-byte key and get
0x00 0x00 0x00... that might be the key, or it might not -- there is
no way to tell by looking at the key itself...

--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
[phone]