RE: Lucre fixed?

Subject: RE: Lucre fixed?
From: Kuehn, Ulrich (Ulrich.Kuehndresdner-bank.com)
Date: Mon Dec 06 1999 - 04:37:04 CST

• Next message: Jeremey Barrett: "Re: ICQ security"
• Previous message: Ben Laurie: "Re: Secure generation of primes"
• Maybe in reply to: Ben Laurie: "Lucre fixed?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> -----Original Message-----
> From: lcs Mixmaster Remailer [mailto:mixanon.lcs.mit.edu]
> The PSS-R variant would be especially appropriate as a
> one-way function
> for Lucre, as it allows the x seed value to be embedded in the padded
> coin y. The specific one-way function is:
>
> y = 0 (1 bit) || w (160 bits) || g1(w) xor r (160 bits) || g2(w) xor x
>
> || is concatenation
> x is the seed, which should be the size of the modulus - 321 bits.
> r is a random factor, 160 bits long
> w is SHA ( x || r )
>
> A hash function g(w) is defined to produce output equal in size to the
> size of the modulus - 161 bits. This can be synthesized out of SHA by
> doing SHA( 0 || w ) || SHA( 1 || w ) || SHA(2 || w ) ...
>
A hsort question about that: The PSS description (Bellare, Rogaway. The
exact security of digital signatures -- how to sign with RSA and Rabin) uses
this way of combining the hash functions. But in a preceeding paper on Full
domain hash
(same authors, Random oracles are practical: a paradigm for designing
efficient protocols) the authors propose to use a truncated version of the
output of the actual hash function to overcome problems arising from the
inner workings of the hash functions themselves.
Can someone point out the security implications of this change?

Regards,
Ulrich

• Next message: Jeremey Barrett: "Re: ICQ security"
• Previous message: Ben Laurie: "Re: Secure generation of primes"
• Maybe in reply to: Ben Laurie: "Lucre fixed?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b27 : Mon Dec 06 1999 - 07:03:12 CST