Implementation of ANSI-X9.63-KDF

Hello ALl,

  Where can I find implementation of key derivation function ANSI-X9.63-KDF to use with ECDH (RFC 3278)? I
didn't find it in OpenSSL or CryptLib.

--

-- 
Best regards,
Maxim Masiutin                          mailto:max <at> ritlabs.com

Maximum length in octets of messages that can be hashed

Hello Ietf-Smime,

  Secion 3.6.1 of "SEC 1: Elliptic Curve Cryptography"
http://www.secg.org/download/aid-385/sec1_final.pdf defines

"hashmaxlen" as "the maximum length in octets of messages that can be hashed using Hash".

  Where can I find the maximum lenght of message for SHA-1, SHA-224(etc). I've searched through fip180-1 and
didn't find any limitation. ANSI-X9.63 also imposes the limitation. Why then the authors ANSI-X9.63 did
define the hashmaxlen limitation if there is no such limitation practically?

--

-- 
Best regards,
Maxim Masiutin                          mailto:max <at> ritlabs.com

Re: Maximum length in octets of messages that can be hashed

Look at the message padding section of the SHA-1 algorithm 
specification.  The length of the "original message" is encoded in 
the padding.  The technique places an upper bound on the number of 
bits that can be hashed.

Russ

At 08:14 AM 3/5/2009, Maxim Masiutin wrote:

>Hello Ietf-Smime,
>
>   Secion 3.6.1 of "SEC 1: Elliptic Curve Cryptography" 
> http://www.secg.org/download/aid-385/sec1_final.pdf defines
>
>"hashmaxlen" as "the maximum length in octets of messages that can 
>be hashed using Hash".
>
>   Where can I find the maximum lenght of message for SHA-1, 
> SHA-224(etc). I've searched through fip180-1 and didn't find any 
> limitation. ANSI-X9.63 also imposes the limitation. Why then the 
> authors ANSI-X9.63 did define the hashmaxlen limitation if there is 
> no such limitation practically?
>
>--
>Best regards,
>Maxim Masiutin                          mailto:max <at> ritlabs.com

Re: Maximum length in octets of messages that can be hashed

Hello,

In the message archived at
   http://www.IMC.ORG/ietf-smime/mail-archive/msg03319.html,
Maxim Masiutin wrote:

> Section 3.6.1 of "SEC 1: Elliptic Curve Cryptography"
> http://www.secg.org/download/aid-385/sec1_final.pdf defines
> "hashmaxlen" as "the maximum length in octets of messages
> that can be hashed using Hash".
>
> Where can I find the maximum length of message for SHA-1,
> SHA-224(etc). I've searched through fip180-1 and didn't
> find any limitation. ANSI-X9.63 also imposes the limitation.
> Why then the authors ANSI-X9.63 did define the hashmaxlen
> limitation if there is no such limitation practically?

Hmmm. What version of FIPS 180 did you skim over?  (See note below.)

In the current version, FIPS 180-3, published in October 2008,
the Introduction (Section 1), at the bottom of the first text
page, contains a table labelled "Figure 1" which I guess can
legitimately be translated into ASCII text.  It says:

Algorithm | Message Size | Block Size | Word Size | Message Digest Size
          |    (bits)    |   (bits)   |  (bits)   |       (bits)
----------+--------------+------------+-----------+--------------------
 SHA-1    |   < 2**64    |     512    |     32    |         160
 SHA-224  |   < 2**64    |     512    |     32    |         224

Re: Implementation of ANSI-X9.63-KDF

In the message archived at
  http://www.IMC.ORG/ietf-smime/mail-archive/msg03318.html,
Maxim Masiutin wrote:

> Where can I find implementation of key derivation function
> ANSI-X9.63-KDF to use with ECDH (RFC 3278)?
> I didn't find it in OpenSSL or CryptLib.

The designated successor of RFC 3278, draft-ietf-smime-3278bis,
available e.g. at:
  http://tools.ietf.org/html/draft-ietf-smime-3278bis-05
gives you (in Section 7.1.8) a pointer to the description of the
method now considered authoritative by the SMIME WG, because of
its barrier-free availablility: Section 3.6.1 of SEC-1 (pp.29/30).

The algorithm is trivial to implement once you have an
implementation of the hash function available; besides that,
it only makes use of octet string concatenation and basic
32-bit integer (index) arithmetics.  Typical hash function
APIs will allow optimizations to avoid the interior string
concatenations, replacing them by incremental (partial) hash
function calls, and the hash output concatenation will also
not be performed explicitely, but by pointer addressing;
intermediate state saving techniques might be applied for further
optimization, but that will go far beyond the typical needs in
EC context, with much shorter shared secrets than in RSA cases.

Kind regards,
  Alfred Hönes.

Re[2]: Maximum length in octets of messages that can be hashed

Hello Russ,

Thank you very much FIP 180-2 gives a clarification: "When a message of any length < 2^64 bits (for SHA-1 and
SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to an algorithm, the result is an output called a
message digest.

--

-- 
Best regards,
Maxim Masiutin                     
Ritlabs SRL
http://www.ritlabs.com/

I-D Action:draft-ietf-smime-new-asn1-03.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.

	Title           : New ASN.1 Modules for CMS and S/MIME
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-smime-new-asn1-03.txt
	Pages           : 62
	Date            : 2009-03-09

The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1.  The current ASN.1 modules
conform to the 1988 version of ASN.1.  This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list

Re: A contradiction between RFC3852 and RFC3278

Maxim,

I don't have any objection to adding the note to draft-smime-3278bis.

spt

Maxim Masiutin wrote:
> Hello Sean,
> 
> In all CMS messages that I’ve seen, when RSA algorithm is used, SignatureAlgorithm in the SignerInfo is
rsaEncryption, not md5WithRSAEncryption. That’s why it made confusion when I was implementing
elliptic curves.
> Maybe, if an update of RFC3852 is planned, we will add a clarification for this?
> Also, while RFC3278-bis is in the draft status, what about adding a clarification that hash in
SignatureAlgorithm and DigestAlgorithm must match?
> 
> 

Re[2]: A contradiction between RFC3852 and RFC3278

Hello Sean,

Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to
the following:

     - signatureAlgorithm contains the signature algorithm identifier 
       (see Section 7.1.3) where the public key part of it
       is ECDSA and the hash part MUST refer to the same algorithm as 
       specified in the digestAlgorithm field. signatureAlgorithm MUST
       be one of the following ecdsa-with-SHA1, 
       ecdsa-with-SHA224, ecdsa-with-SHA256, 
       ecdsa-with-SHA384, or ecdsa-with-SHA512. 

--

-- 
Best regards,
Maxim Masiutin                     
Ritlabs SRL
http://www.ritlabs.com/

[Technical Errata Reported] RFC4134 (1716)

The following errata report has been submitted for RFC4134,
"Examples of S/MIME Messages".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4134&eid=1716

--------------------------------------
Type: Technical
Reported by: Maxim Masiutin <max <at> ritlabs.com>

Section: 4.8 & 4.9

Original Text
-------------
aliceDss <at> examples.com

Corrected Text
--------------
AliceDSS <at> example.com

Notes
-----
"From" line of the RFC-822 message is aliceDss <at> examples.com, while the certificate’s
SubjectAlternativeName contains Rfc822Name = AliceDSS <at> example.com

So the two emails are different in the host part:

aliceDss <at> examples.com