|> 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
participants (3)
-
anon1df3＠nyx10.cs.du.edu -
Black Unicorn -
Nathan Loofbourrow