Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Crypt-Rijndael CPAN distribution.

Report information
The Basics
Id: 97258
Status: open
Priority: 0/
Queue: Crypt-Rijndael
People
Owner: Nobody in particular
Requestors: RURBAN [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Tue Jul 15 13:16:28 2014 RURBAN [...] cpan.org - Ticket created
Subject: Insecure, do not use. Use Crypt::OpenSSL::AES instead
This simple C reference implementation is too insecure to be used. It was already cracked via cache timing attacks. Use the secure Crypt::OpenSSL::AES instead, which uses the proper openssl HW or fallback to asm implementation with timing attack countermeasures instead. http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://www.jbonneau.com/doc/BM06-CHES-aes_cache_timing.pdf and tons of other AES cache timing attack papers. -- Reini Urban
  Thu Jul 17 12:29:02 2014 DANAJ [...] cpan.org - Correspondence added
On Tue Jul 15 13:16:28 2014, RURBAN wrote: Show quoted text
> This simple C reference implementation is too insecure to be used. It > was already cracked via cache timing attacks. > > Use the secure Crypt::OpenSSL::AES instead, which uses the proper > openssl HW or fallback to asm implementation with timing attack > countermeasures instead. > > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf > http://www.jbonneau.com/doc/BM06-CHES-aes_cache_timing.pdf > and tons of other AES cache timing attack papers.
Wouldn't replacing this implementation with an alternate implementation be another option? With Crypt::OpenSSL::AES, you're using whatever happens to get loaded in libcrypt at runtime. We can hope that it is an error-free version of actual OpenSSL... This assumes that there is a good and correct alternate AES implementation available, and that we none of this is rendered moot by someone managing to have alternate versions of the Perl modules loaded. Also see http://www.hyperelliptic.org/SPEED/slides09/kasper-aes_speedcc09_slides.pdf including the cautions about simple implementations and link to newer implementations at the end.
  Thu Jul 17 12:29:03 2014 The RT System itself - Status changed from 'new' to 'open'
  Thu Jul 17 13:22:46 2014 rurban [...] x-ray.at - Correspondence added
Subject: Re: [rt.cpan.org #97258] Insecure, do not use. Use Crypt::OpenSSL::AES instead
Date: Thu, 17 Jul 2014 12:22:33 -0500
To: bug-Crypt-Rijndael [...] rt.cpan.org
From: Reini Urban <rurban [...] x-ray.at>
On Thu, Jul 17, 2014 at 11:29 AM, Dana Jacobsen via RT <bug-Crypt-Rijndael@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=97258 > > > On Tue Jul 15 13:16:28 2014, RURBAN wrote:
>> This simple C reference implementation is too insecure to be used. It >> was already cracked via cache timing attacks. >> >> Use the secure Crypt::OpenSSL::AES instead, which uses the proper >> openssl HW or fallback to asm implementation with timing attack >> countermeasures instead. >> >> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf >> http://www.jbonneau.com/doc/BM06-CHES-aes_cache_timing.pdf >> and tons of other AES cache timing attack papers.
> > Wouldn't replacing this implementation with an alternate implementation be another option? With Crypt::OpenSSL::AES, you're using whatever happens to get loaded in libcrypt at runtime. We can hope that it is an error-free version of actual OpenSSL...
Well, you can never be sure with openssl, but it's at least multitudes better than the current naive version in Crypt-Rijndael. openssl got much more eyes, and Crypt-Rijndael got zero. Show quoted text
> This assumes that there is a good and correct alternate AES implementation available, and that we none of this is rendered moot by someone managing to have alternate versions of the Perl modules loaded.
Relying on standard security libraries is much better then relying on a bad and unmaintained implementation. These attacks are known for a decade. Show quoted text
> Also see http://www.hyperelliptic.org/SPEED/slides09/kasper-aes_speedcc09_slides.pdf including the cautions about simple implementations and link to newer implementations at the end.
Of course bernsteins version looks better, but qhasm is not really portable. openssl is. good qhasm versions do exist for ppc32, x86, sparcv9 and amd64. Personally I would only trust bernstein and polarssl, not openssl nor libressl, but we cannot have everything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
  Thu Jul 17 21:45:35 2014 bdfoy [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #97258] Insecure, do not use. Use Crypt::OpenSSL::AES instead
Date: Thu, 17 Jul 2014 21:44:45 -0400
To: bug-Crypt-Rijndael [...] rt.cpan.org
From: brian d foy <bdfoy [...] cpan.org>
Show quoted text
> Well, you can never be sure with openssl, but it's at least multitudes > better than the current naive version in Crypt-Rijndael. openssl got > much more eyes, and Crypt-Rijndael got zero.
I take your point about Crypt::Rijndael, which is effectively unmaintained. I kept it up to ensure it would install but there have been no major code changes in years. I'm thinking about how to deprecate the module. First, I think we should track down anything that depends on it and get them to switch. (https://metacpan.org/requires/distribution/Crypt-Rijndael?sort=[[2,1]]) But the number of eyes don't matter. All those eyes on openssl didn't matter when no one fixed the problems that those eyes saw. :) -- brian d foy <brian.d.foy@gmail.com> http://www.pair.com/~comdog/
  Tue May 26 19:01:26 2015 LEONT [...] cpan.org - Correspondence added
On Thu Jul 17 12:29:02 2014, DANAJ wrote: Show quoted text
> On Tue Jul 15 13:16:28 2014, RURBAN wrote:
> > This simple C reference implementation is too insecure to be used. It > > was already cracked via cache timing attacks. > > > > Use the secure Crypt::OpenSSL::AES instead, which uses the proper > > openssl HW or fallback to asm implementation with timing attack > > countermeasures instead. > > > > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf > > http://www.jbonneau.com/doc/BM06-CHES-aes_cache_timing.pdf > > and tons of other AES cache timing attack papers.
> > Wouldn't replacing this implementation with an alternate > implementation be another option? With Crypt::OpenSSL::AES, you're > using whatever happens to get loaded in libcrypt at runtime. We can > hope that it is an error-free version of actual OpenSSL...
Agreed. It should not be particularly hard to replace the current block_encrypt and block_decrypt functions with an alternative implementation, that would be a far easier solution to the ecosystem. The remaining question is: which one should that be? Leon