Folks:
Regarding earlier discussion on these lists about "the difficulty of
factoring" and "post-quantum cryptography" and so on, you might be
interested in this note that I just posted to the tahoe-dev list:
"100-year digital signatures"
http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/00443
On 13/06/2010 05:21, Zooko O'Whielacronx wrote:
> Folks:
>
> Regarding earlier discussion on these lists about "the difficulty of
> factoring" and "post-quantum cryptography" and so on, you might be
> interested in this note that I just posted to the tahoe-dev list:
>
> "100-year digital signatur
On Wed, Sep 1, 2010 at 2:55 PM, Ben Laurie wrote:
>>
>> Therefore, you would end up hashing your messages with a
>> secure hash function to generate "message representatives" short
>> enough to sign.
> Way behind the curve here, but this argument seems incorrect. Merkle
> signatures rely on the p
On 01/09/2010 22:45, Zooko O'Whielacronx wrote:
> On Wed, Sep 1, 2010 at 2:55 PM, Ben Laurie wrote:
>> Or, to put it another way, in order to show that a Merkle signature is
>> at least as good as any other, then you'll first have to show that an
>> iterated hash is at least as secure as a non-ite
On Fri, Sep 03, 2010 at 09:45:20AM +0100, Ben Laurie wrote:
>
> That's the whole point - a hash function used on an arbitrary message
> produces one of its possible outputs. Feed that hash back in and it
> produces one of a subset of its possible outputs. Each time you do this,
> you lose a little
On 09/03/2010 03:45 AM, Ben Laurie wrote:
That's the whole point - a hash function used on an arbitrary message
produces one of its possible outputs. Feed that hash back in and it
produces one of a subset of its possible outputs. Each time you do this,
you lose a little entropy (I can't remember
On 03/09/2010 17:01, Marsh Ray wrote:
> I played with some simulations with randomly-generated mappings, the
> observed value would at times wander over 1.0 BoE/log2 N.
I think when I did this, I fully enumerated the behaviour of a truncated
hash (e.g. the first 20 bits of MD5).
Cheers,
Ben.
--
On 09/03/2010 01:22 PM, Ben Laurie wrote:
On 03/09/2010 17:01, Marsh Ray wrote:
I played with some simulations with randomly-generated mappings, the
observed value would at times wander over 1.0 BoE/log2 N.
I think when I did this, I fully enumerated the behaviour of a truncated
hash (e.g. the
On Sat, 4 Sep 2010 10:45:48 +1000 (EST) Dave Horsfall
wrote:
> Funny you should mention that. Back in the late 70s, a work
> colleague suggested that the Unix crypt() function was a ring (we
> both had mathematical backgrounds), which gave me the idea of
> repeatedly encrypting the encrypted root
On Fri, Sep 3, 2010 at 10:29 AM, Jack Lloyd wrote:
> On Fri, Sep 03, 2010 at 09:45:20AM +0100, Ben Laurie wrote:
>
> ...narrow-pipe designs have a huge null space for messages
> which are exactly as big as the compression function input
> size. For instance hashing inputs that are multiples of 512
I want to rewind the discussion a bit.
Things being said here range from the outright true, to the
true-but-irrelevant, all the way to being a canard.
There is a core question that we're not addressing at all, and that is: "How
much security does a hash function have?" There is no good answer t
11 matches
Mail list logo
