h...@finney.org ("Hal Finney") writes:
> Paul Hoffman wrote:
>> Getting a straight answer on whether or not the recent preimage work
>> is actually related to the earlier collision work would be useful.
[...]
> There was an amusing demo at the rump session though of a different
> kind of preimage
Paul Hoffman wrote:
> Getting a straight answer on whether or not the recent preimage work
> is actually related to the earlier collision work would be useful.
I am not clueful enough about this work to give an authoritative answer.
My impression is that they use some of the same general technique
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
Ben Laurie wrote:
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything neede
While thinking about Zooko's problem with needing small keys, I seem to
have recalled an idea for a DSA variant that uses small keys. I can't
remember where I heard it, maybe at a Crypto rump session. I wonder if
anyone recognizes it.
Let the DSA public key be y = g^x mod p. DSA signatures are def
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anything needed for "pluggability" beyond versioning?
>
> It seems to me protocol designers get all excited about this because
> they want to d
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> Perry E. Metzger wrote:
> > Yet another reason why you always should make the crypto algorithms you
> > use pluggable in any system -- you *will* have to replace them some day.
>
> In order to roll out a new crypto algorithm, you have t
At 9:39 AM -0400 8/25/09, Perry E. Metzger wrote:
>Ben Laurie writes:
> > Perry E. Metzger wrote:
>>> Yet another reason why you always should make the crypto algorithms you
>>> use pluggable in any system -- you *will* have to replace them some day.
>>
>> In order to roll out a new crypto algorit
Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed
On Tue, 25 Aug 2009, Ben Laurie wrote:
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anything needed for "pluggability" beyond versioning?
If active attackers are part of the threat model, then you need to
worry about version-rollback attacks for as
Ben Laurie writes:
> Perry E. Metzger wrote:
>> Yet another reason why you always should make the crypto algorithms you
>> use pluggable in any system -- you *will* have to replace them some day.
>
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anyt
Perry E. Metzger wrote:
> Yet another reason why you always should make the crypto algorithms you
> use pluggable in any system -- you *will* have to replace them some day.
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed for "pluggability"
11 matches
Mail list logo
