Re: PGP 2.5

|> Another RSAREF limitation is that it cannot cope with keys longer than
|> 1024 bits.  PGP now prints a reasonably polite error message in such a
|> case.

|Reasonably polite?  It says "Error: Bad pass phrase."  That doesn't
|sound at all polite to me.  And since my key is 1234 bits, I'm vastly
|unimpressed.  What in the world is the point of this restriction?

|I see a lot of "what it is" but not "why it is" in the docs.  Would one of

This restrcition comes from RSAREF code, over which the PGP team had no 
control.

Everyone is entitled to their own opinion, but to me the development of a 
free, legal, source code version of PGP is such a positive development 
that it easily outweighs any of the problems (key sigs, incompatibility 
with big keys, etc.) that the new release has brought about.  When the 
jump from verison 1 to verison 2 was made, everyone's key became 
obsolete, and everyone survived.  Everyone will survive this time, too.

I'm also very pleased with some of the new features (like the default for 
PGPPATH, which will make PGP a lot more accessible to casual users).

> 
> |> Another RSAREF limitation is that it cannot cope with keys longer than
> |> 1024 bits.  PGP now prints a reasonably polite error message in such a
> |> case.
> 
> |Reasonably polite?  It says "Error: Bad pass phrase."  That doesn't
> |sound at all polite to me.  And since my key is 1234 bits, I'm vastly
> |unimpressed.  What in the world is the point of this restriction?
> 
> |I see a lot of "what it is" but not "why it is" in the docs.  Would one of
> 
> This restrcition comes from RSAREF code, over which the PGP team had no 
> control.
> 
> Everyone is entitled to their own opinion, but to me the development of a 
> free, legal, source code version of PGP is such a positive development 
> that it easily outweighs any of the problems (key sigs, incompatibility 
> with big keys, etc.) that the new release has brought about.

I'm afraid I have to disagree.
 
I dislike the limiting of key length to 1024 bits and would encourage a 
fix to at least the 1200's range.
 
Unfortunately I don't know enough about RSAREF to know what this involves 
but it seems a step backwards to limit key length to this size especially 
with the recent advances in processing on the retail market (powerpc 
pentium etc.)  To me this makes 2.5 a real loser.
 
More and more 2.5 looks like a restriction on choice.

No keys over 1024 bits.
No use of servers for the older versions.



> When the 
> jump from verison 1 to verison 2 was made, everyone's key became 
> obsolete, and everyone survived.  Everyone will survive this time, too.

I don't use a 1200 bit key now, but I'd like the option.  Calling the 
limitation a mere backwards compatibility problem shortcuts the issue.  I 
wouldn't care less if I used a 1200 bit key or a 2048 bit key today and 
had to make a new one for the new version.  I would care if I used a 1200 
or 2048 bit key today and had to make a 1024 bit one.

I don't want to be paranoid, but why the restriction?  Who does it 
serve?   Definitely not the user.  What modifications are possible?  What 
are the restrictions on modification to code in the licensing agreement?


> 
> I'm also very pleased with some of the new features (like the default for 
> PGPPATH, which will make PGP a lot more accessible to casual users).
>

Fine, how about satisfactory for serious users?

-uni- (Dark)

Paul Grange writes:
 > |> Another RSAREF limitation is that it cannot cope with keys longer than
 > |> 1024 bits.  PGP now prints a reasonably polite error message in such a
 > |> case.
 > 
[...]
 > This restrcition comes from RSAREF code, over which the PGP team had no 
 > control.

Strange -- the RSAREF 2.0 license asserts no such restriction, unless
I've misread it. Patching it -- say, to allow it to handle >1024 bit
keys -- would seem to fall under one's license...

[from license.txt]
     c.   to modify the Program in any manner for porting or
          performance improvement purposes (subject to Section 2)
          or to incorporate the Program into other computer programs
          for your own personal or internal use, provided that you
          provide RSA with a copy of any such modification or
          Application Program by electronic mail, and grant RSA a
          perpetual, royalty-free license to use and distribute such
          modifications and Application Programs on the terms set
          forth in this Agreement.

Is the definition of "performance improvement" so limited that
improving maximum key size is not permitted?

This aside, modifying RSAREF 2.0 (and taking out the guardrails in
keymgmt.c) *appears* to allow larger key sizes. The only succeeding
restriction on key sizes is the 1280-bit restriction imposed by the
assembly code, if the comments are to be believed.

Generating a brand new ~1280 bit key under 2.5 appears to work
perfectly, although I suppose RSAREF could be happily returning a
shorter key that claims to be >1024 bits (either by design, or by
omission). The fact that an older >1024 bit key fails this test does
raise this suspicion.

This will take some further work. I would be surprised to discover
that the MIT folk hadn't fiddled with this at all, though -- Any
comment from the 2.5 folks on the barriers to using RSAREF for longer
keys?

nathan