Re: new IKE draft
"Sumit Vakil"<Sumit_Vakil@mw.3com.com> Mon, 16 March 1998 22:49 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10190 for ipsec-outgoing; Mon, 16 Mar 1998 17:49:36 -0500 (EST)
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: Sumit Vakil <Sumit_Vakil@mw.3com.com>
To: ipsec@tis.com
Message-ID: <862565C9.007ED929.00@mwgate02.mw.3com.com>
Date: Mon, 16 Mar 1998 17:05:57 -0600
Subject: Re: new IKE draft
Mime-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
According to PKCS#1, the length of the data to be encrypted must not be more than k-11 octets, where k is the modulus length. PKCS#1 has two interesting notes in section 8: 3. Application of private-key operations as defined here to data other than an octet string containing a message digest is not recommended and is subject to further study. 4. This standard may be extended to handle data of length more than k-11 octets. Is there a standard that describes how to do #4? That would answer how to encrypt longer octet strings. Also, what about #3 above? The Id payload certainly isn't a message digest. Thanks, Sumit A. Vakil 3Com, Corp. pau@watson.ibm.com on 03/16/98 09:50:34 AM To: matt@ljo.dec.com cc: ipsec@tis.com, hugo@ee.technion.ac.il, canetti@watson.ibm.com Subject: Re: new IKE draft Matt : > > > >7. impose limits on the size of nonces: 8 <= len(nonce) <= 256 (section 5) > > 3 March email from Tero Kivinen and 4 March email from Hilarie Orman > > Just one question, in the the RSA Encryption modes don't the nonces need to > be smaller than the RSA modulus (so they can be encrypted/decrypted)? > (Also what happens in the non-Revised mode if the identification payload is > larger than what can be encrypted via the RSA modulus?) I think you are right. Actually, for stronger securuty, I think the input to RSA encryption should not be longer than 2/3 of the size of the modulus. Hugo and Ran, am I right about this ? > > Also, in the RSA Encryption modes you can specify a hash of the certificate > you are using. How do you calculate the hash (since you have not finished > negotiating the hash algorithm)? In main mode, this "cert-hash" is not sent until after negotiation is comopleted. In aggressive mode, well, you have to be careful about what you propose. Not only the hash algorithms have to be the same in all proposed transforms, but the encryption algorithms, the prfs (if any), the authentication methods and the groups have to be the same as across proposed transforms as well. As far as I can tell, the only thing that can be different in aggressive mode is the life time. Pau-Chen > -- > Matt Thomas Internet: matt.thomas@altavista-software.com > Internet Locksmith WWW URL: <coming eventually> > AltaVista Internet Software Disclaimer: This message reflects my own > Littleton, MA warped views, etc.
- new IKE draft Daniel Harkins
- Re: new IKE draft Matt Thomas
- Re: new IKE draft pau
- Re: new IKE draft Sumit Vakil
- Re: new IKE draft Lewis McCarthy
- Re: new IKE draft Lewis McCarthy
- Re: new IKE draft Lewis McCarthy