Re: SNMPv2 security

[[e-mail]]

Frank Kastenholz says:
> 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.

But in cryptography "new key" means new key - and normally
one doesn't tell his opponent exactly _how_ he changed the
key.  And that's just what you're doing sending the update
over in clear.

> 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.

Great. So I can assume this is generally understood (:-).

>  > Thus - what do we save by "changing" the key in such a funny way?
> 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?

Of course not. Don't you see, that introducing relations
between the old and the new keys is what normal
cryptographers are avoiding at any cost?

Don't you see the difference between sending Knew encrypted
with something secure and not exposed and encrypting it
with old worn-out key?

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

As was shown before, and by me - you don't need to have Kold to
be able to use all the traffic protected by both Kold and Knew
to crack the Key, and it's irrelevant whether you attack Kold
or Knew, as long as they're related so linearly. When you
use DES, at least it's not that easy to reverse the
relation between Kold and Knew. With XOR - ...

> 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.

???

The whole idea of changing keys is to prevent an adversary from
accumulating enough of traffic to crack the key - that's why
it's retired (and also to limit the exposure in case it got
exposed, of course :-). I fail to see how DES becomes less
robust in such scheme, because it was designed with
known-plaintext and even chosen-plaintext attacks
in mind.

Also, if you change the key because you might suspect Kold is
compromised - it's insanity to protect the Knew with Kold...

> 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.

Yeah, that's SOME robustness... Would you trust your life to it?

> P.S. There is an interesting additional bit of security in the XOR
> scheme that is not in DES.

If you really believe it's security - I have nothing to add.

> 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.

Yes, that attack was described in 1976 by Diffie and Hellman.
Then such a machine would cost $200,000,000 (if my memory
serves me), today I guess you could build one for $20M.

> 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...

Yeah, an adversary doesn't have all the previous traffic,
he doesn't know how they key is used, e doesn't know the
algorithm used, he doesn't know what MD5 is,  he doesn't
know... Oh well... Nice world!
--
Regards,
Uri         [e-mail]      scifi!angmar!uri 	N2RIU
-----------
<Disclamer>