Re: FIPS
Vikram Arwade wrote: ... Also is it OK to build using “perl Configure fipscanisterbuild solaris-sparcv9-cc” or do we need to use “./config fipscanisterbuild”? If we need to use “./config fipscanisterbuild” then how do we build on solaris sparcv9 using studio 11? Not if you're planning to call the result FIPS 140-2 validated. The Security Policy and User Guide are both (IMHO) excruciatingly clear on that point. You can't use the v1.2 module on a platform for which the module as validated (including the Security Policy build instructions) is not suitable. Those build instructions presume a default build environment for the host O/S distribution, i.e. what you get when you procure and install that distribution in the usual and customary way. Granted, there is a bit of a gray area concerning the nature of that usual and customary environment. The installation of standard vendor supplied patches and upgrades presumably does not invalidate the host O/S distribution (I say presumably because only the CMVP can make any authoritative judgments). Installation of a vendor supplied optional compiler (where more than one such is available) would presumably also be allowed, as would standard well-known third-party libraries or tools. I'm not familiar with Studio 11 but it does appear to be a vendor supplied and supported development product, so it might be acceptable provided that it is installed in such a way that is constitutes the default compiler, linker, etc., so that ./config fipscanisterbuild works. Changing the module code or those build command incantations is clearly *not* allowed, period. Keep in mind that all you need is fipscanister.o itself. Too many software vendors seem to think they have to fit the fipscanister.o build from the source tarball into their own specific internal build process. The CMVP has already staked out a claim on a particular special process leaving little latitude for creative reinterpretation. It may be a lot easier to create fipscanister.o as a separate independent step, as defined and required in the Security Policy, and *then* throw the resulting fipscanister.o into the special ornate and elaborate internal process. It may even be appropriate to image a standalone build machine with a stock O/S distribution just for the purposes of creating fipscanister.o, as that file can then be moved to a non-standard but ABI compatible platform. -Steve M. -- Steve Marquess The OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ 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, 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
[Fwd: [opensc-user] using engine_pkcs11 programmatically]
I had asked this on the opensc-users list, but realized its more of an openssl question. using the wclient2.c sample program [1] from this article [2] as a starting place http://www.linuxjournal.com/article/5487 http://www.rtfm.com/openssl-examples/openssl-examples-20020110.tar.gz I want to use engine_pkcs11 [3] to provide the client authentication of an ssl connection via a USB pki token, but I have yet to find any programming documentation, The engine_pkcs11 I've built seems to work with the command line examples, but now I need to use it in a C program to authenticate an ssl session. In that wclient2 sample program, the connect sequence is ... ctx=initialize_ctx(KEYFILE,PASSWORD); SSL_CTX_set_cipher_list(ctx,ciphers); sock=tcp_connect(host,port); ssl=SSL_new(ctx); sbio=BIO_new_socket(sock,BIO_NOCLOSE); SSL_set_bio(ssl,sbio,sbio); if(SSL_connect(ssl)=0) berr_exit(SSL connect error); if(require_server_auth) check_cert(ssl,host); any tips, pointers, references, etc on how I can figure this out? there doesn't seem to be any API documentation on using this engine at all, the only docs I see on the opensc wiki are a command line example. Since i originally asked the above, I've gathered that I do this with the ENGINE_x [4] api's of openssl (btw, you know I only found that man page with google, I don't see any links to it on [5] So, I guess what I'm asking is for a tutorial or howto or cookbook example of using ENGINE_ to invoke the engine_pkcs11 from [3] in order to use a token to do ssl client authentication. [1] http://www.rtfm.com/openssl-examples/openssl-examples-20020110.tar.gz [2] http://www.linuxjournal.com/article/5487 [3] http://www.opensc-project.org/engine_pkcs11/ [4] http://www.openssl.org/docs/crypto/engine.html [5] http://www.openssl.org/docs/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL RAM usage
Hello, I am looking for benchmarks on OpenSSL RAM usage in embedded devices. Also trying to find ways to reduce it. Any pointers? I understand it should be an FAQ but does not seem to be in the list. Thanks, JLS
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: trying to understand ECDHE operations
Dave, Thank you very much for your efforts. I must be doing something incorrect, as today I tried to re-run what I had done before, and the Linux PC running the s_client crashes processing the certificate. I am running snapshot builds. If you don't mind me pestering a bit more, how did you run the test? Thanks, I appreciate your help. Mike --- On Mon, 9/28/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Monday, September 28, 2009, 7:16 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 25 September, 2009 09:32 Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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: FIPS
Thanks Steve. Do you know why my make test must be failing? if [ -n libcrypto ]; then \ ../util/shlib_wrap.sh ./fips_shatest SHAmix.req | diff -w SHAmix.fax - ; \ fi ERROR:2d072065:lib=45,func=114,reason=101:file=fips_rand_selftest.c:line =364: 1,129d0 [L = 64] Len = 16 Msg = 98a1 MD = 74d78642f70ca830bec75fc60a585917e388cfa4cd1d23daab1c4d9ff1010cac3e67275d f64db5a6a7c7d0fda24f1fc3eb272678a7c8becff6743ee812129078 Len = 104 Msg = 35a37a46df4ccbadd815942249 MD = 6f5589ea195e745654885d50de687d7fe682affc8da1fb09e681540525f04ecb93022361 a27759b9e272c883564223c5e4ecafeb0daaf1abce6caa4bd4153379 Regards, --Vikram -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Steve Marquess Sent: Tuesday, September 29, 2009 4:23 AM To: openssl-users@openssl.org Subject: Re: FIPS Vikram Arwade wrote: ... Also is it OK to build using perl Configure fipscanisterbuild solaris-sparcv9-cc or do we need to use ./config fipscanisterbuild? If we need to use ./config fipscanisterbuild then how do we build on solaris sparcv9 using studio 11? Not if you're planning to call the result FIPS 140-2 validated. The Security Policy and User Guide are both (IMHO) excruciatingly clear on that point. You can't use the v1.2 module on a platform for which the module as validated (including the Security Policy build instructions) is not suitable. Those build instructions presume a default build environment for the host O/S distribution, i.e. what you get when you procure and install that distribution in the usual and customary way. Granted, there is a bit of a gray area concerning the nature of that usual and customary environment. The installation of standard vendor supplied patches and upgrades presumably does not invalidate the host O/S distribution (I say presumably because only the CMVP can make any authoritative judgments). Installation of a vendor supplied optional compiler (where more than one such is available) would presumably also be allowed, as would standard well-known third-party libraries or tools. I'm not familiar with Studio 11 but it does appear to be a vendor supplied and supported development product, so it might be acceptable provided that it is installed in such a way that is constitutes the default compiler, linker, etc., so that ./config fipscanisterbuild works. Changing the module code or those build command incantations is clearly *not* allowed, period. Keep in mind that all you need is fipscanister.o itself. Too many software vendors seem to think they have to fit the fipscanister.o build from the source tarball into their own specific internal build process. The CMVP has already staked out a claim on a particular special process leaving little latitude for creative reinterpretation. It may be a lot easier to create fipscanister.o as a separate independent step, as defined and required in the Security Policy, and *then* throw the resulting fipscanister.o into the special ornate and elaborate internal process. It may even be appropriate to image a standalone build machine with a stock O/S distribution just for the purposes of creating fipscanister.o, as that file can then be moved to a non-standard but ABI compatible platform. -Steve M. -- Steve Marquess The OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ 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: OpenSSL RAM usage
It's been a while since I applies OpenSSL to a pure embedded environment, but it's quite doable. No RAM figures available now, but such are very application dependent anyway (how many connections are open at the same time; how many SSL contexts, etc.etc.); I find coding the functionality in a portable way so that you can run it on a desktop box too (Win32 or UNIX) is quite useful here as well: there you've got a plethora of tools to monitor task memory usage, so you can see what the footprint will be about. (Compiler and platform differences...) One can cut down the ROM footprint of OpenSSL as well by configuring it to use a reduced number of crypto algorithms (the various 'no-xyz' config options, where xyz is a cipher, e.g. no-rc5). Then there's the choice whether or not to support 'engines' and you can also select which SSL protocols you wish to support in your embedded build (NO_SSL2), further reducing your code size. From there, it's stripping some definition tables, which reference functions, e.g. in the SSL, EVP and BIO sections, which, when you want to eke out every last byte of ROM space, must be done by tweaking the code in a few spots. This helps the linker as a few more functions can then be discarded. But take heed: this is reduction process which is highly dependent on your particular needs. Since OpenSSL uses several standard C run-time library calls (such as the FILE* I/O functions -- which can be stripped as well, using NO_FP) I have found that the easiest route there is to simulate those when the embedded system does not offer such libraries. It's been too long ago and my brain is too fuzzy about it to mention RAM/ROM foo5tprint numbers now I obtained that way back then. The major work on this was back around Y2K. So far, my 2 cents. On Tue, Sep 29, 2009 at 8:29 PM, Jose Stein jlui...@gmail.com wrote: Hello, I am looking for benchmarks on OpenSSL RAM usage in embedded devices. Also trying to find ways to reduce it. Any pointers? I understand it should be an FAQ but does not seem to be in the list. Thanks, JLS -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL RAM usage
You might want to check out MatrixSSL (http://www.matrixssl.org) which is a fairly successful attempt to provide a SSL implementation for embedded systems. --- On Tue, 9/29/09, Jose Stein jlui...@gmail.com wrote: From: Jose Stein jlui...@gmail.com Subject: OpenSSL RAM usage To: openssl-users@openssl.org Date: Tuesday, September 29, 2009, 9:59 PM Hello, I am looking for benchmarks on OpenSSL RAM usage in embedded devices. Also trying to find ways to reduce it. Any pointers? I understand it should be an FAQ but does not seem to be in the list. Thanks, JLS
