Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
Hi, Since we are on the subject of hardware enhanced cryptography, does the HiFn chips used in the Soekris devices, have support in openssl?. Regards Nige Kyle Hamilton wrote: OpenSSL uses the operating system to get entropy. If AMD wants Linux to support its on-chip random number generator, it needs to write a driver that replaces /dev/random and /dev/urandom. In addition, Intel has been playing nice and getting its code in the openssl distribution, as a set of patches that were integrated not too long ago. Nobody has submitted such a patch for the Geode to my knowledge (I'm not god of the request tracker, but most mails sent to r...@openssl.org are forwarded to the -dev list; I've not seen any patches come in). (i.e.: Intel is doing strategic positioning that AMD is not.) -Kyle H On Sep 27, 2009, at 11:05 AM, Jelle de Jong wrote: Hello everybody, The AMD Geode LX800 CPU has an on-chip AES 128-bit crypto accelerations block and a true random number generator, but OpenSSL is not using it. Please see the below link for test reports and openssl outputs http://debian.pastebin.com/faeff2a3 Is there anybody that know what is going on here? Thanks in advance, Jelle __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
Hi, Hi, Since we are on the subject of hardware enhanced cryptography, does the HiFn chips used in the Soekris devices, have support in openssl?. yes - for some time now. i happen to have a vpn1401 next to me which I used in a FreeBSD box alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
On Mon, Sep 28, 2009 at 01:54:57PM -0700, Kyle Hamilton wrote: OpenSSL uses the operating system to get entropy. If AMD wants Linux to support its on-chip random number generator, it needs to write a driver that replaces /dev/random and /dev/urandom. ...or feeds into them. Sufficient but not necessary. If AMD have released spec.s in a manner compatible with the kernel license and development model then someone else could write that driver. Some would say that is the preferred method. In addition, Intel has been playing nice and getting its code in the openssl distribution, as a set of patches that were integrated not too long ago. Nobody has submitted such a patch for the Geode to my knowledge (I'm not god of the request tracker, but most mails sent to r...@openssl.org are forwarded to the -dev list; I've not seen any patches come in). (i.e.: Intel is doing strategic positioning that AMD is not.) That's smart of Intel. But again, if AMD have released spec.s under liberal terms then maybe they think they *are* positioning their product, and nobody has picked up on it yet. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Friends don't let friends publish revisable-form documents. smime.p7s Description: S/MIME cryptographic signature
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
On Tue, Sep 29, 2009 at 7:22 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Sep 28, 2009 at 01:54:57PM -0700, Kyle Hamilton wrote: OpenSSL uses the operating system to get entropy. If AMD wants Linux to support its on-chip random number generator, it needs to write a driver that replaces /dev/random and /dev/urandom. ...or feeds into them. Sufficient but not necessary. If AMD have released spec.s in a manner compatible with the kernel license and development model then someone else could write that driver. Some would say that is the preferred method. This may be preferred according to RMS^Wsome... but as long as the code is written, and put under the GPLv2, Linux can use it. In fact, if the code is written, and is released under a new-BSD-style license (without the obnoxious advertising clause), Linux can use it, and so can every other OS. (Even openssl would be able to integrate it for those platforms without explicit support for kernel crypto acceleration.) I know that I'm not going to write code for a CPU that I don't have. (Linus Torvalds even created Linux first in order to explore the capabilities of the i386 chip that he'd just gotten.) If AMD has an itch (we want to build the value proposition for the Geode as opposed to Intel chips) to scratch, then AMD is the entity which needs to scratch it. It really can't wait for someone else to do it, because there's more than enough competition already, and who wants to write code from scratch for one platform when it's already been written and integrated for another? In addition, Intel has been playing nice and getting its code in the openssl distribution, as a set of patches that were integrated not too long ago. Nobody has submitted such a patch for the Geode to my knowledge (I'm not god of the request tracker, but most mails sent to r...@openssl.org are forwarded to the -dev list; I've not seen any patches come in). (i.e.: Intel is doing strategic positioning that AMD is not.) That's smart of Intel. But again, if AMD have released spec.s under liberal terms then maybe they think they *are* positioning their product, and nobody has picked up on it yet. Come on, we're talking about AMD. The company that bought ATI. They might have gotten the impression that there's someone, somewhere, who wants to write code for their chip, because that was the experience that ATI had when they released the specifications for the 3D acceleration of their chips. (Their impression might have been that way because there were a lot of people who'd purchased ATI graphics cards or chips, and had their own itches to scratch -- and had purchased ATI because nVidia refused to make their specs available, and did everything they could to convince the Linux kernel that its binary-only driver would not taint it... by including the four characters GPL\0 at the beginning of their all rights reserved copyright statement.) -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
On 09/27/09 22:36, Alan Buxey wrote: The AMD Geode LX800 CPU has an on-chip AES 128-bit crypto accelerations block and a true random number generator, but OpenSSL is not using it. Please see the below link for test reports and openssl outputs http://debian.pastebin.com/faeff2a3 Is there anybody that know what is going on here? use 'padlock' engine or 'cryptodev' engine? There is no reference to the cryptodev term anywhere in Debian. I think its only part of the OCF-Linux (patches OpenBSD Cryptographic Framework). Why does this not work out of the box with Debian, the technology is pretty old already? Some people that did manual testings ended up in failure with OpenSSL Corrupted MAC on input messages see: http://www.securityfocus.com/archive/121/486751/30/0/threaded http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_Results I am interested in solutions that make it possible to use a standaard Debian kernel and OpenSSL package and get nice hardware crypto accelerations out of the box. Would this be possible? What would be needed? Best regards, Jelle __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
OpenSSL uses the operating system to get entropy. If AMD wants Linux to support its on-chip random number generator, it needs to write a driver that replaces /dev/random and /dev/urandom. In addition, Intel has been playing nice and getting its code in the openssl distribution, as a set of patches that were integrated not too long ago. Nobody has submitted such a patch for the Geode to my knowledge (I'm not god of the request tracker, but most mails sent to r...@openssl.org are forwarded to the -dev list; I've not seen any patches come in). (i.e.: Intel is doing strategic positioning that AMD is not.) -Kyle H On Sep 27, 2009, at 11:05 AM, Jelle de Jong wrote: Hello everybody, The AMD Geode LX800 CPU has an on-chip AES 128-bit crypto accelerations block and a true random number generator, but OpenSSL is not using it. Please see the below link for test reports and openssl outputs http://debian.pastebin.com/faeff2a3 Is there anybody that know what is going on here? Thanks in advance, Jelle __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
Hello everybody, The AMD Geode LX800 CPU has an on-chip AES 128-bit crypto accelerations block and a true random number generator, but OpenSSL is not using it. Please see the below link for test reports and openssl outputs http://debian.pastebin.com/faeff2a3 Is there anybody that know what is going on here? Thanks in advance, Jelle __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
Hi, Hello everybody, The AMD Geode LX800 CPU has an on-chip AES 128-bit crypto accelerations block and a true random number generator, but OpenSSL is not using it. Please see the below link for test reports and openssl outputs http://debian.pastebin.com/faeff2a3 Is there anybody that know what is going on here? use 'padlock' engine or 'cryptodev' engine? alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
