multiple subkeys and key transition

[Ben McGinnes]

On 10/12/10 6:17 AM, Robert J. Hansen wrote:
> On 12/9/10 1:30 PM, Ben McGinnes wrote:
>> Ah, a debate, excellent.  Now let's make it a little more
>> entertaining, where do you see RIPEMD-160 in the scheme of things?
> 
> My suspicion is RIPEMD-160 is broken, we just don't know how.  It
> has an awful lot of mathematical similarities to hashes that have
> been broken: it is my suspicion existing attacks will be successful
> when tweaked to apply to RIPEMD-160.

Okay, I can't say I've been overjoyed at having it as the only
apparent alternative to SHA-1.  I think, however, that the
"enable-dsa2" option you mentioned is working, so that's a much better
solution.

>> Is it possible that this current transition push is partially aimed
>> at reigniting the WG's discussion by creating a new de-facto
>> standard?
> 
> Dunno, ask the WG.

As soon as I find them ...

>>> This statement seems to assume that the RFC can't or won't be
>>> updated in a way that people could make the transition using the
>>> same key material, assuming they were using strong enough keys and
>>> digests in the first place.
>>
>> What is the likelihood of that actually being the case?
> 
> IMO, quite high.  If you use the same key material, then if the old
> OpenPGP certificate format ever becomes weak an attacker can simply
> take an old certificate of yours, upgrade it to the new format, and
> bang they're off to the races.

Nasty.

> If/when the time comes for SHA-1 to be completely removed from
> OpenPGP, the migration path will quite likely involve new keys --
> the same way that the V3/V4 migration path in the past necessitated
> new keys.

That sounds an awful lot like the reason behind creating my current
key.  Actually, that's not true, there's a set from about six months
earlier that I thought I new the passphrase to, but ... you know the
rest of that tale (just about everyone does that at least once).  ;)

>> Since I prefer a more long-term approach, this should eventually
>> lead to 8,192-bit encryption keys when 4,096-bit becomes the
>> default.
> 
> It is unlikely it ever will.  3K RSA keys are believed to be
> equivalent to a 128-bit symmetric key.  If computational power ever
> develops to that point, the solution is going to involve moving to
> entirely different algorithms instead of just tacking on another
> couple of bits.

Well, I have rather enjoyed the fact that the 4096-bit Elgamal key I
created a dozen years ago is still considered practically impossible
to defeat (not counting if I ever managed to piss off the NSA/DSD).
Any larger would start getting a bit ridiculous (although I do know
which bit of keygen.c to tweak to make it possible).


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101210/7e531002/attachment.pgp>