Re: Some SHA-2 news
On Sat, 19 Feb 2011 14:55:14 -0500 Robert J. Hansen r...@sixdemonbag.org articulated: On 2/19/11 9:53 AM, lists.gn...@mephisto.fastmail.net wrote: Think we'll see this included one day in OpenPGP, or will we just skip to SHA-3 when it's ready? Usually, algorithms are added due to existing users with a strong need -- e.g., CAMELLIA came about because users in the Pacific Rim needed it. I'm unaware of anyone saying, the SHA-2s are great, but they're too slow on 64-bit processors. And until there is, the odds of OpenPGP adoption are practically nil, IMO. Out of simple morbid curiosity, other than the time and effort needed to adopt the code, is there any downside to this venture? -- Jerry ✌ gnupg.u...@seibercom.net _ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Some SHA-2 news
Jerry wrote: On Sat, 19 Feb 2011 14:55:14 -0500 Robert J. Hansen r...@sixdemonbag.org articulated: On 2/19/11 9:53 AM, lists.gn...@mephisto.fastmail.net wrote: Think we'll see this included one day in OpenPGP, or will we just skip to SHA-3 when it's ready? Usually, algorithms are added due to existing users with a strong need -- e.g., CAMELLIA came about because users in the Pacific Rim needed it. I'm unaware of anyone saying, the SHA-2s are great, but they're too slow on 64-bit processors. And until there is, the odds of OpenPGP adoption are practically nil, IMO. Out of simple morbid curiosity, other than the time and effort needed to adopt the code, is there any downside to this venture? The downside is not just the time and effort to adopt and include this new method. New code increases the risks of introducing new bugs. Personal thought: With the exception of some much older SPARC and Alpha*, aren't 64-bit platforms usually at the higher end of the performance charts? Why speed up there? If work is needed to speed up cryptographic functions, why not concentrate on the cell phone/PDA end of the performance spectrum where it is truly needed? * - I'm sure there exist other older 64-bit architectures (MIPS, POWER,...). I only included those which I regularly use. -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Some SHA-2 news
On Sun, Feb 20, 2011 at 07:19:15AM -0500 Also sprach Jerry: On Sat, 19 Feb 2011 14:55:14 -0500 Robert J. Hansen r...@sixdemonbag.org articulated: On 2/19/11 9:53 AM, lists.gn...@mephisto.fastmail.net wrote: Think we'll see this included one day in OpenPGP, or will we just skip to SHA-3 when it's ready? Usually, algorithms are added due to existing users with a strong need -- e.g., CAMELLIA came about because users in the Pacific Rim needed it. I'm unaware of anyone saying, the SHA-2s are great, but they're too slow on 64-bit processors. And until there is, the odds of OpenPGP adoption are practically nil, IMO. Out of simple morbid curiosity, other than the time and effort needed to adopt the code, is there any downside to this venture? I can't really see much downside, except, as has been noted, a possible lack of demand. I don't believe security is affected one way or the other. It's just a matter of a slight performance improvement on certain hardware. With SHA-3 so close on the horizon, though, I find it doubtful that a minor re-working of SHA-2 would gather much adoption. It somewhat surprises me, even, that NIST bothered with it. I suppose someone, somewhere, must be saying the SHA-2s are great, but they're too slow... or why would anyone have put the work in to extend the standard, as has been done? I think understanding this was the motivation for my original post. pgpY8kpGwg6eU.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Some SHA-2 news
On 2/20/11 5:00 PM, John Clizbe wrote: Personal thought: With the exception of some much older SPARC and Alpha*, aren't 64-bit platforms usually at the higher end of the performance charts? Why speed up there? If work is needed to speed up cryptographic functions, why not concentrate on the cell phone/PDA end of the performance spectrum where it is truly needed? Some mobile devices use 64-bit processors. E.g., the Cell processor is 64-bit, as are some Atom variants. As more 64-bit processors get thrown into mobile devices, fast 64-bit code becomes more important. At present 64-bit procs are a substantial minority, but this will change quickly in the next few years. Apple seems pretty married to 32-bit ARM architecture for their mobile devices: the rest of the world seems pretty eager to shift. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Some SHA-2 news
The downside is not just the time and effort to adopt and include this new method. New code increases the risks of introducing new bugs. Agreement and addendum: it also increases the amount of code that has to be supported going into the future. There's a rule in software engineering, usually called the second system effect. In essence, the first release of a software release has a tendency to be better than subsequent releases. The first release only does what it absolutely has to do: subsequent releases get weighted down by all the bells and whistles people want but which never actually get used. Look at Microsoft Word: as time has gone on, Microsoft Word has exploded in complexity to the point where it might actually be bigger and more complicated than Windows itself. (Before anyone accuses me of MS-bashing, Free Software has lots of examples, too.) Good software engineers fight the second-system effect tooth and nail. Part of that means limiting what new bells and whistles get added. So, yeah: in addition to what John says about the risk factor, there's also the second-system factor. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
