gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] session ticket support


From: Simon Josefsson
Subject: Re: [PATCH] session ticket support
Date: Tue, 04 Aug 2009 14:15:33 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)

Daiki Ueno <address@hidden> writes:

> * New interface functions as you suggested.
>
>   int gnutls_session_ticket_allocate_key (gnutls_session_ticket_key_t *);
>   int gnutls_session_ticket_randomize (gnutls_session_ticket_key_t);
>   int gnutls_session_ticket_import (gnutls_session_t, void *, size_t);
>   int gnutls_session_ticket_export (gnutls_session_t, void *, size_t *);

I suggest renaming these APIs like this:

 gnutls_session_ticket_key_allocate
 gnutls_session_ticket_key_randomize
 gnutls_session_ticket_key_import
 gnutls_session_ticket_key_export

Also, what do you think about a 'gnutls_session_ticket_key_format_t'
parameter?  I think some people may want to export the key in
text-format rather than raw binary.

Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
won't be good choices forever.  How about changing the randomize
function into:

 int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
                                          gnutls_cipher_algorithm_t cipher,
                                          gnutls_mac_algorithm_t mac);

The docstring should recommend applications to use AES-128 and
HMAC-SHA-256.

I see that some struct sizes in the RFC (like IV and MAC size) are hard
coded, so it may not be worth time to extrapolate that part to support
non-AES-128/HMAC-SHA-256 options.  So
gnutls_session_ticket_key_randomize could return an error if other
choices than AES-128/HMAC-SHA-256 are used.  This means the API is ready
if RFC 5077bis defines support for HMAC-SHA-3 or similar.

Thanks,
/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]