headers
Marcus Watts | 1 Apr 2003 09:31
Picon

AES and SHA-1 timing

I'm still trying to understand Raeburn's claim that he can get do
pbkdf2 in slightly under 1 second don a 300 Mhz pentium II.  But I now
have a strong hunch.  I think he must be linking against a fairly
recent version of openssl, and using the sha-1 code from there.  That
is a super souped up assembler version (generated by a perl script)
which I believe is especially optimized for the pentium II.  My belief
is that if he were using the sha-1 code in the MIT kerberos 5
distribution, that he would see much more leisurely string to key
conversion times, like 4-5 seconds.

For what it's worth, in the process of understanding this,
I wrote an assembly version and compared the speed of various
versions of stuff.  My best assembly version is here:
	http://www-personal.umich.edu/~mdw/shs.tar
I got more interested in this after I discovered that the
latest heimdal snapshot had AES in it, and it's faster than
what I had.  How embarassing.

Here are timings I got for SHA-1 on various machines -- probably
more interesting for relative value since I don't know the
clock rates on some:

	SHA-1, microseconds to hash N bytes
	mdw assembler	k5 C		openssl 0.9.7a
N	16	8192	16	8192	16	8192
486	86	9147	141	17080	98	10350
pentII	6.36	607	8.83	1147	4.45	541
athlon	1.7	169			(2.4	280)*
pent4/M	1.21	101	4.08	526	1.59	168
	* = openssl 0.9.6
(Continue reading)

Permalink | Reply | 2 comments |
headers
Douglas E. Engert | 1 Apr 2003 21:58
Favicon

[Fwd: WG Last Call: Clarifications and AES] - Reminder

Just a reminder to the WG, that we are in Last Call on these two documents.
You have one week left for comments.

-------- Original Message --------
Subject: WG Last Call: Clarifications and AES
Date: Mon, 17 Mar 2003 23:03:39 -0600
From: "Douglas E. Engert" <deengert <at> anl.gov>
To: Kerberos WG <ietf-krb-wg <at> anl.gov>
CC: Russell Housley <housley <at> vigilsec.com>,"Steven M. Bellovin" <smb <at> research.att.com>

The Clarifications and AES drafts is now ready for krb-wg WG last call. 
We are starting the WG Last call process, which will last three weeks
and end on April 8. (I am adding the extra week as we have two documents, 
and Clarifications is 133 pages long.) 

There is one typo in the ASN.1 in Clarifications. The line 
in Section 5.2.7.5 which reads:

ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY

Should read:

ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

Clarifications can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-03.txt

AES can be found at:
http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael-krb-03.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 3 Apr 2003 17:41
Picon
Favicon

Comments on draft-raeburn-krb-rijndaelkrb-03

I went through what I hope is one last review of the AES document.

In section 9, the following text has a comma just after a preposition:

    attack is through preauthentication mechanisms that provide better
    protection of, the user's long-term key.  Use of such mechanisms is
    out of scope for this document.

Also, in section 9:

    Also, generating a 256-bit key from a pass phrase of any length may
    be deceptive, since the effective entropy in pass-phrase-derived key
    cannot be nearly that large.

Is there some reason we do not mention the explicit limit of sha-1
(160 bits)?  Are we concerned there might be a slightly lower upper
limit because of the s2k function that we don't really know?

I did not confirm the accuracy of the test vectors although I did look
at whether sufficient test vectors were included to make
interoperability likely.

Having reviewed the document, I would like to recommend it for
publication.  I have not yet thought about Marcus's comments on AES
timing; it seems that at worst we would need to change the default
iteration count to address these comments.
Permalink | Reply | 3 comments |
headers
Love | 3 Apr 2003 17:59
Picon
Picon
Favicon

Re: Comments on draft-raeburn-krb-rijndaelkrb-03

hartmans <at> mit.edu (Sam Hartman) writes:

> I did not confirm the accuracy of the test vectors although I did look
> at whether sufficient test vectors were included to make
> interoperability likely.

I've tested the vectors with the AES implemetation in Heimdal.

Love
Permalink | Reply | 0 comments |
headers
Sam Hartman | 3 Apr 2003 18:40
Picon
Favicon

Comments on draft-ietf-krb-wg-kerberos-clarifications-03 section 2


The following text is not grammatical:

 Some implementations of RFC 1510 are known
    to reject unknown KDC options, so clients may need to resend a
    request without KDC new options absent if the request was rejected
    when sent with option added since RFC 1510. 

Replace KDC new options absent with new KDC options.  Replace option
added with options added.

In section 2.8, I do not understand the meaning of the dangling
phrase:

    encrypted part of the KDC reply indicates to the client that the
    server (not the client) specified in the ticket has been determined
    by policy of the realm to be a suitable recipient of delegation.  A
    client can use the presence of this flag to help it make a decision
    whether to delegate credentials (either grant a proxy or a forwarded
    ticket-granting ticket) to this server.  Ignore the value of this
    flag. When setting this flag, an administrator should consider the
    Security and placement of the server on which the service will run,
    as well as whether the service requires the use of delegated
    credentials.
Permalink | Reply | 0 comments |
headers
Sam Hartman | 3 Apr 2003 22:52
Picon
Favicon

Comments on draft-ietf-krb-wg-kerberos-clarifications-03 section 3

The following transition across paragraph breaks does not work:

    format for the ticket is described in section 5.3. The contents of
    the ticket are determined as follows.

    Because Kerberos can run over unreliable transports such as UDP, the
    KDC MUST be prepared to retransmit responses in case they are lost.

In section 3.2.2 there is a reference to the old section 6.  I think
the entire parenthetical should be removed as the crypto draft is very
clear on this point.

    modification of the ticket (each encryption system MUST provide
    safeguards to detect modified ciphertext; see section 6), the
    KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that

Later, decisions is used instead of decision:

    Applications MUST make a separate authorization decisions based upon
    the authenticated name of the user, the requested operation, local
    access control information such as that contained in a .k5login or
    .k5users file, and possibly a separate distributed authorization
    service.

I'm fairly certain I've commented on this in the past, but I still
find the description of subkey usage in section 3.2.6 both wrong from
a security design standpoint and incompatible with the Kerberos crypto
framework.  IN the interest of getting something published I propose
that the discussion of subkey stop just before the phrase "To make
this example more concrete."  We should cut from that phrase to the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ken Raeburn | 3 Apr 2003 23:05
Picon
Favicon

Re: crypto draft changes


> New draft: http://www.mit.edu/~raeburn/draft-ietf-krb-wg-crypto-04.txt

I've finally gotten this submitted to the I-D queue.  The submitted
text is identical to the version I mentioned here two weeks ago.

Ken
Permalink | Reply | 0 comments |
headers
Ken Raeburn | 4 Apr 2003 00:08
Picon
Favicon

Re: Comments on draft-raeburn-krb-rijndaelkrb-03

hartmans <at> MIT.EDU (Sam Hartman) writes:
> I went through what I hope is one last review of the AES document.
>
> In section 9, the following text has a comma just after a preposition:
>
>     attack is through preauthentication mechanisms that provide better
>     protection of, the user's long-term key.  Use of such mechanisms is
>     out of scope for this document.

Noted, thanks.

> Also, in section 9:
>
>     Also, generating a 256-bit key from a pass phrase of any length may
>     be deceptive, since the effective entropy in pass-phrase-derived key
>     cannot be nearly that large.
>
> Is there some reason we do not mention the explicit limit of sha-1
> (160 bits)?  Are we concerned there might be a slightly lower upper
> limit because of the s2k function that we don't really know?

I am not sufficiently familiar with analysis of such things to say how
that relates to the effective entropy of the final key.  Indeed, I
probably should've consulted someone who is before including that
statement.

I think it's entirely accurate to say that any pass phrase used by a
human is unlikely to present anywhere near 256 bits of randomness, but
I'm not convinced it's impossible, especially if the pass phrase is
long, machine generated and never used by a human.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sam Hartman | 4 Apr 2003 00:54
Picon
Favicon

Comments on draft-ietf-krb-wg-kerberos-clarifications-03 section 5


In 5.2.6.2, the text claims that the same checksum is used as was used
to protect the ticket.  Unfortunately, tickets are not actually
protected by Kerberos checksums so this text is misleading.  The text
should describe what key is used for the checksum (is it the service
key?  Is it the session key? I think either would be secure) and
should probably say that you use the checksum algorithm required to be
implement along with that encription type.  

Later text seems to say server key  That's fine.  I think that will
should be changed to MUST in the following text; the requirement is
important for security and thus I think requirements language is
critical.

    element will be ignored by the application server if this "signature"
    is not present. Further, elements encapsulated within this element
    from a ticket-granting ticket MAY be interpreted by the KDC, and used
    as a basis according to policy for including new signed elements
    within derivative tickets, but they will not be copied to a
    derivative ticket directly. If they are copied directly to a
    derivative ticket by a KDC that is not aware of this element, the
    signature will not be correct for the application ticket elements,
    and the field will be ignored by the application server.
In the following text, the spelling of encapsulates is wrong:

    This element and the elements it encapulates MAY be safely ignored by
    applications, application servers, and KDCs that do not implement
    this element.

Text in 5.2.7.3 and 5.2.7.4 confuses me.  I thought we were moving
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Hartman | 4 Apr 2003 01:03
Picon
Favicon

Re: Comments on draft-raeburn-krb-rijndaelkrb-03

>>>>> "Ken" == Ken Raeburn <raeburn <at> MIT.EDU> writes:

    Ken> So, I'm not convinced the 160-bit limit of sha-1 necessarily
    Ken> applies to pbkdf2.  But I couldn't assert that it does not,
    Ken> either.

OK, I actually misunderstood pbkdf2 and withdraw my comment; your text
sounds reasonable based on the reality of the situation.
Permalink | Reply | 0 comments |

Gmane