Re: SNMPv2 security
Frank Kastenholz <kasten@tri-flow.ftp.com> Mon, 31 January 1994 15:50 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05735; 31 Jan 94 10:50 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05731; 31 Jan 94 10:50 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa04929; 31 Jan 94 10:50 EST
Received: by relay.tis.com; id AA28700; Mon, 31 Jan 94 10:29:32 EST
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.0mjr) id sma028685; Mon Jan 31 10:28:37 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa21912; 31 Jan 94 10:20 EST
Received: from sol.tis.com by magellan.TIS.COM id aa21908; 31 Jan 94 10:11 EST
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21141; Mon, 31 Jan 94 10:10:55 EST
Received: by relay.tis.com; id AA28565; Mon, 31 Jan 94 10:11:27 EST
Received: from babyoil.ftp.com(128.127.2.105) by relay via smap (V1.0mjr) id sma028557; Mon Jan 31 10:10:59 1994
Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA18521; Mon, 31 Jan 94 10:10:50 -0500
Received: by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA13053; Mon, 31 Jan 94 10:10:39 EST
Date: Mon, 31 Jan 1994 10:10:39 -0500
Message-Id: <9401311510.AA13053@tri-flow.ftp.com.ftp.com>
To: uri@watson.ibm.com
Subject: Re: SNMPv2 security
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@tri-flow.ftp.com>
Reply-To: kasten@ftp.com
Cc: romanov@nacto.lkg.dec.com, snmp@psi.com, snmpv2@magellan.tis.com
Content-Length: 2424
> 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. Yes, this is a weakness -- the only part of the key update message that is protected is the key itself. But you can use a party-pair that includes privacy if you wish. Remember, the XOR algorithm is the minimum required, it is not the maximum that you may do. > > > 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? You are not introducing a relation between the new key and the old key. The new key is chosen in some manner that (presumably) decouples its value from the old key's value -- say a true random number generator. > Don't you see the difference between sending Knew encrypted > with something secure and not exposed and encrypting it > with old worn-out key? Look, either Kold is compromised or it isn't. If it is compromised, it does not matter whether you send Knew encrypted with DES/Kold, or XORing Knew and Kold. Either way, the bad guy has Kold and can read Knew. If Kold is not compromised, that is, it is still a secret, then you can send Knew either XOR'd with Kold, or DES-Encrypted with Kold. It won't matter. Remember that using SNMPv2 to update keys is going to be secure if and only if Kold is secure. If you believe that Kold has been compromised then, in order to maintain security, you should resort to some other mechanism to distribute new keys (probably manual distribution). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000
- Re: SNMPv2 security Frank Kastenholz
- Re[2]: SNMPv2 security cyoung
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security uri
- Re: SNMPv2 security uri
- Re: SNMPv2 security Frank Kastenholz
- Re: SNMPv2 security Julie Tarr
- Re: SNMPv2 security Keith McCloghrie
- Re: SNMPv2 security Julie Tarr
- Re: SNMPv2 security Sath. Nelakonda
- Re: SNMPv2 security michael (m.) sam chee