Mailing List Archive

On Fri, 2004-07-23 at 21:06, Roger Moser wrote:
> One rule in cryptography is to use the same key only once. But SRS (or SES)
> uses the same secret key for many different email addresses. So the secret
> key could be guessed, if it is too short.
>
> Therefore my question to the crypto experts amongst you is:
>
> What is minimum recommended length of the secret key used to generate the
> cryptographic hash so that the secret key cannot be guesses by cryptographic
> analysis of email addresses modified by SRS?

512 bits for SHA-160, and ideally they would be all truly random too.

Cheers,

James


--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Le samedi 24 Juillet 2004 13:17, James Couzens a écrit :
> >
> > What is minimum recommended length of the secret key used to generate the
> > cryptographic hash so that the secret key cannot be guesses by
> > cryptographic analysis of email addresses modified by SRS?
>
> 512 bits for SHA-160, and ideally they would be all truly random too.

If I understand well, the default length of the SRS generated hash is 4
characters, base-64 encoded, which makes "24 bits of security" according to
http://www.libsrs2.org/srs/srs.pdf , §4.2

This actually looks quite short to me, especially as $4.1 of the same document
states that the hash comparison will pass with only a warning if the case of
the hash would have been modified. I wonder if this doesn't reduce the
security of the hash to about 20 bits for a 4-characters hash...

I understood (maybe I'm mistaken) that the secret should be made of characters
from the base-64 set. So if we would want a 512-bit equivalent secret, we
would need a secret made of 86 base-64 characters ;-)

--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E

Michel Bouissou a écrit:

> This actually looks quite short to me, especially as $4.1 of the same
document
> states that the hash comparison will pass with only a warning if the case
of
> the hash would have been modified. I wonder if this doesn't reduce the
> security of the hash to about 20 bits for a 4-characters hash...

That is no problem because even with a hash of only 20 bits the spammer
would have to send one million mails to get one through.

Roger

On Sat, 2004-07-24 at 05:38, Roger Moser wrote:

> That is no problem because even with a hash of only 20 bits the spammer
> would have to send one million mails to get one through.

That may not be so ;)

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo--
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

James Couzens wrote:

>> What is minimum recommended length of the secret key used to generate
>> the cryptographic hash so that the secret key cannot be guesses by
>> cryptographic analysis of email addresses modified by SRS?

> 512 bits for SHA-160, and ideally they would be all truly random too.

SRS uses HMAC-SHA1 where the key is limited to 64 bits. What was the reason
to use HMAC-SHA1 instead of SHA-1 applied to the concatenation of a secret
key (without length limit) and the string to hash?

Roger

I wrote:

> SRS uses HMAC-SHA1 where the key is limited to 64 bits. What was the
reason
> to use HMAC-SHA1 instead of SHA-1 applied to the concatenation of a
secret
> key (without length limit) and the string to hash?

Sorry I read "64 bits" instead of "64 bytes". So please ignore my question.

Roger

On Sat, 24 Jul 2004, Roger Moser wrote:
>
> SRS uses HMAC-SHA1 where the key is limited to 64 bits. What was the reason
> to use HMAC-SHA1 instead of SHA-1 applied to the concatenation of a secret
> key (without length limit) and the string to hash?

The reason for using HMAC rather than simply using a cryptographic hash of
the message and a key to form a MAC is that HMAC is more resistant to
attacks that involve replay of the original data concatenated with data
from the attacker.

Tony.
--
f.a.n.finch <dot@dotat.at> http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.

On Sat, 24 Jul 2004, Roger Moser wrote:

> James Couzens wrote:
>
> >> What is minimum recommended length of the secret key used to generate
> >> the cryptographic hash so that the secret key cannot be guesses by
> >> cryptographic analysis of email addresses modified by SRS?
>
> > 512 bits for SHA-160, and ideally they would be all truly random too.
>
> SRS uses HMAC-SHA1 where the key is limited to 64 bits. What was the reason
> to use HMAC-SHA1 instead of SHA-1 applied to the concatenation of a secret
> key (without length limit) and the string to hash?

The reason for the existence of HMAC (and hence the use of HMAC/SHA1
instead of SHA1) is that the simple crypto algorithms can under some
circumstances have weaknesses or leak information, especially on very
short data sets. HMAC removes this weakness, given certain assumptions
which hold for both MD5 and SHA1.

I'm afraid I don't have a Schneier green book to hand, but I'm sure either
that or the red book explain this more fully. For example, from RFC2104:
"MD5 has been recently shown to be vulnerable to collision search attacks.
This attack and other currently known weaknesses of MD5 do not compromise
the use of MD5 within HMAC as specified in this document"

The reason for the choice of SHA1 over MD5 is entirely political: Certain
government or high level organisations require the use of SHA1 over MD5
for certain purposes, and I was advised that the choice of SHA1 was likely
to ease the adoption of this protocol in places with a strong political
cryptographic agenda.

S.

--
Shevek http://www.anarres.org/
Robust Sender Policy Framework (SPF) http://www.libspf2.org/
SRS for the next generation http://www.libsrs2.org/