headers
Don Johnson | 1 Feb 1999 16:29

Re: A New Triple-DES Key Wrap Algorithm

Russ,

A few comments:
1. An integrity value of 16 bits is not enough to thwart a determined
attacker, especially if using a integrity verification oracle, that is,
toss values at it until success.
2. Given that TDES CBC is being done for messages, why not do two-pass TDES
CBC for the key wrapping (that is, do CBC over the key block and then do it
again)?  This avoids the need for code for a formatting method.  This forms
a block where every bit is dependent on every other bit.  A triple-DES key
is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
384, this gives 192 bits for other stuff.  Put in some random bits, put in
a longer checksum, put in a length of the block,  put in other stuff,
depending on what attributes are desired.  The TDES blocksize being
64-bits, text attacks are not relevant as 2**32 blocks of key data will not
get encrypted under one set of TDES keys, and as it is random-appearing
data, is the best thing to encrypt anyway.

Don Johnson

Russ Housley <housley <at> spyrus.com> on 01/31/99 06:17:38 PM

To:   ietf-smime <at> imc.org
cc:   burt <at> RSA.COM, djohnson <at> certicom.ca, schneier <at> counterpane.com,
      denny <at> tis.com, denning <at> cs.cosc.georgetown.edu, omura <at> cylink.com,
      mhetzel <at> bell-labs.com, benaloh <at> microsoft.com, brickell <at> certco.com,
      mjmarkowitz <at> attmail.com, smatyas <at> vnet.ibm.com, paulv <at> entrust.com,
      merkle <at> parc.xerox.com, berson <at> anagram.com, desmedt <at> uwm.edu,
      rivest <at> theory.lcs.mit.edu, carlisle.adams <at> entrust.com,
      ams <at> terisa.com, ekr <at> rtfm.com, Blake.greenlee <at> greenlee.com,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 1 Feb 1999 17:54
Picon
Favicon

I-D ACTION:draft-ietf-smime-x942-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

Note: This revision reflects comments received during the last call period.

	Title		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-05.txt
	Pages		: 12
	Date		: 29-Jan-99
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-x942-05.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 1 Feb 1999 20:48

Re: A New Triple-DES Key Wrap Algorithm

Don:

>1. An integrity value of 16 bits is not enough to thwart a determined
>attacker, especially if using a integrity verification oracle, that is,
>toss values at it until success.

A slight restructuring could lead to 32 bits.  This would eliminate the
Length value and the Pad octet.  Any additional would lead to an additional
block.  This is already six blocks to protect three blocks of data.

>2. Given that TDES CBC is being done for messages, why not do two-pass TDES
>CBC for the key wrapping (that is, do CBC over the key block and then do it
>again)?  This avoids the need for code for a formatting method.  This forms
>a block where every bit is dependent on every other bit.  A triple-DES key
>is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
>384, this gives 192 bits for other stuff.  Put in some random bits, put in
>a longer checksum, put in a length of the block,  put in other stuff,
>depending on what attributes are desired.  The TDES blocksize being
>64-bits, text attacks are not relevant as 2**32 blocks of key data will not
>get encrypted under one set of TDES keys, and as it is random-appearing
>data, is the best thing to encrypt anyway.

Are you saying that the original formatting with double encryption would be
a cheaper way to resolve the problems raised by Burt kaliski?  Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass?  If so, it needs to be carried somewhere.  Is
disclosure an issue?  Alternatively, can a differnt constant IV be used for
the second pass?

Thanks for the speedy review,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Johnson | 1 Feb 1999 21:22

Re: A New Triple-DES Key Wrap Algorithm

Russ,

My comments imbedded in your note and prefixed with an *.
Don J.

Russ Housley <housley <at> spyrus.com> on 02/01/99 02:48:01 PM

To:   Don Johnson/Certicom
cc:   ietf-smime <at> imc.org, burt <at> RSA.COM, djohnson <at> certicom.ca,
      schneier <at> counterpane.com, denny <at> tis.com,
      denning <at> cs.cosc.georgetown.edu, omura <at> cylink.com,
      mhetzel <at> bell-labs.com, benaloh <at> microsoft.com, brickell <at> certco.com,
      mjmarkowitz <at> attmail.com, smatyas <at> vnet.ibm.com, paulv <at> entrust.com,
      merkle <at> parc.xerox.com, berson <at> anagram.com, desmedt <at> uwm.edu,
      rivest <at> theory.lcs.mit.edu, carlisle.adams <at> entrust.com,
      ams <at> terisa.com, ekr <at> rtfm.com, Blake.greenlee <at> greenlee.com,
      cme <at> acm.org, bfox <at> microsoft.com, acc <at> tycho.ncsc.mil,
      bschanni <at> BayNetworks.com, jhs <at> tycho.ncsc.mil, jis <at> mit.edu,
      pcain <at> bbn.com, kent <at> bbn.com, BSnow <at> radium.ncsc.mil,
      cjwagne <at> missi.ncsc.mil, balenson <at> tis.com, jlinn <at> securitydynamics.com,
      smid <at> csmes.ncsl.nist.gov
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Don:

>1. An integrity value of 16 bits is not enough to thwart a determined
>attacker, especially if using a integrity verification oracle, that is,
>toss values at it until success.

A slight restructuring could lead to 32 bits.  This would eliminate the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 1 Feb 1999 23:56
Picon

SecureConnect 2

Greetings again. A few of the companies attending SecureConnect 2 have
noted to me that I didn't send mail to the PKIX or S/MIME WG mailing lists.
I guess my non-spam traits got the better of me.

SecureConnect 2 is the interoperability event for S/MIME clients and CAs,
to be held February 23-24. Folks out in The Real World have been finding
that many (but not all) of the interoperability issues in deployed S/MIME
clients are in the certificate handling. Thus, it would be good to get all
of today's S/MIME client vendors and CA vendors together to do more
in-depth testing.

More information on SecureConnect 2 can be found at
<http://www.imc.org/imc-secureconnect/>.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 0 comments |
headers
John Ross | 3 Feb 1999 01:30
Picon
Picon

Re: KEKRecpientInfo KEKIdentifier

I agree it could be optional in CMS.  But  it should be mandated either in
MSG, or it may be better mandated in ESS. For example, ESS could mandate
that the KEKIdentifier must be present when secure mailing lists are used.

Regards

John Ross
-----Original Message-----
From: Russ Housley <housley <at> spyrus.com>
To: EKR <ekr <at> rtfm.com>
Cc: pgut001 <at> cs.aucKland.ac.nz <pgut001 <at> cs.aucKland.ac.nz>;
ietf-smime <at> imc.org <ietf-smime <at> imc.org>
Date: Friday, January 29, 1999 2:36 PM
Subject: Re: KEKRecpientInfo KEKIdentifier

>What do others think?
>
>I am unwilling to make it optional without a change to MSG that mandates it
>for S/MIME.
>
>Russ
>
>
>At 08:58 AM 1/29/99 -0800, EKR wrote:
>>pgut001 <at> cs.aucKland.ac.nz (Peter Gutmann) writes:
>>> almost never be used in the way you've described.  PGP has worked just
fine
>>> for 8 years without a KEKIdentifier, so I don't see why CMS needs to
>make it
>>> mandatory.  All you need to do is use "kekid [ 0 ] KEKIdentifier
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 2 Feb 1999 22:55
Picon
Favicon

Re: A New Triple-DES Key Wrap Algorithm

Russ,

For the benefit of those of us who weren't following the discussion all 
that closely, could you summarize your original submission (and the 
rationale behind it), and the attack which Burt Kalisky found against it?

BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
but I don't have their current e-mail addresses.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman <at> novell.com
1-801-861-7387

>>> "Don Johnson" <djohnson <at> certicom.com> 02/01/99 01:22PM >>>
Russ,

My comments imbedded in your note and prefixed with an *.
Don J.

Russ Housley <housley <at> spyrus.com> on 02/01/99 02:48:01 PM

To:   Don Johnson/Certicom
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Schneier | 2 Feb 1999 23:11

Re: A New Triple-DES Key Wrap Algorithm

At 02:55 PM 2/2/99 -0700, Bob Jueneman wrote:
>Russ,
>
>For the benefit of those of us who weren't following the discussion all 
>that closely, could you summarize your original submission (and the 
>rationale behind it), and the attack which Burt Kalisky found against it?
>
>BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
>Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
>but I don't have their current e-mail addresses.
>
>Bob

It is an impressive list, but don't assume that just because someone is on
the 
list that they have analyzed the system.  Russ is looking for free
cryptanalysis,
and the best way to get that is to send email to everyone and hope that
someone
has nothing better to do that day.  It's a good way to have bad systems
broken,
but it is less effective at showing that good systems are actually good.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Pawling | 2 Feb 1999 23:32

Re: KEKRecpientInfo KEKIdentifier

All,

I believe that the KEKRecpientInfo KEKIdentifier should not be optional.
The recipient always needs to have a means of identifying which KEK to use
to process the received message.  

- John Pawling

At 05:17 PM 1/29/99 -0500, Russ Housley wrote:
>What do others think?
>
>I am unwilling to make it optional without a change to MSG that mandates it
>for S/MIME.
>
>Russ
>
>
>At 08:58 AM 1/29/99 -0800, EKR wrote:
>>pgut001 <at> cs.aucKland.ac.nz (Peter Gutmann) writes:
>>> almost never be used in the way you've described.  PGP has worked just fine 
>>> for 8 years without a KEKIdentifier, so I don't see why CMS needs to
>make it 
>>> mandatory.  All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" 
>>and 
>>> you can let the users decide whether it really is essential or not - I'm
>not 
>>> asking that it be removed, simply that it be made optional so you can 
>>leave it 
>>> out where there's nothing to put in a KEKIdentifier.
>>I've got to go with Peter here. While I think that for messaging,
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Pawling | 2 Feb 1999 23:43

RE: Last Call Comments on CMS-10

All,

I believe that a version 3 SignerInfo MUST cause the parent SignedData
version to be 3.  This strategy allows the receiving software to be able to
distinquish between an S/MIME v2 or v3 message by looking at the first field
in the signedData.

- John Pawling

At 02:12 PM 1/12/99 -0800, Jim Schaad (Exchange) wrote:
>Russ:
>
>> -----Original Message-----
>> From: Russ Housley [mailto:housley <at> spyrus.com]
>> Sent: Tuesday, January 12, 1999 11:36 AM
>> To: Jim Schaad (Exchange)
>> Cc: Ietf-Smime (E-mail)
>> Subject: Re: Last Call Comments on CMS-10

<snip>

>> >7.  Section 5.1: Text on version needs to be expanded to 
>> deal with SKI.
>> >Must be 3 if any SignerInfo version is 3.
>> 
>> Are you saying that a version 3 SignerInfo should cause 
>> parent SignedData
>> version to be 3?
>> 
>> Is there a reason to prohibit version 3 SignerInfo from being
(Continue reading)

Permalink | Reply | 1 comment |

Gmane