Re: [openssl-users] Fips CTR_DRBG
I can do mutch more i can give the source code:
#include iostream
using std::cout;
using std::endl;
#include stdlib.h
#include openssl/evp.h
#include openssl/err.h
#include fips/fips_rand.h
#include fips/fips_rand_lcl.h
#include openssl/rand.h
#include string.h
typedef struct
{
const unsigned char *ent;
size_t entlen;
int entcnt;
const unsigned char *nonce;
size_t noncelen;
int noncecnt;
} TEST_ENT;
static unsigned char dummy_drbg_entropy[1024];
static unsigned char entropy_x[32];
static unsigned char nonce[16];
static size_t test_entropy(DRBG_CTX *dctx, unsigned char **pout,
int entropy, size_t min_len, size_t
max_len)
{
TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
*pout = (unsigned char *)t-ent;
t-entcnt++;
return t-entlen;
}
static size_t test_nonce(DRBG_CTX *dctx, unsigned char **pout,
int entropy, size_t min_len, size_t
max_len)
{
TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
*pout = (unsigned char *)t-nonce;
t-noncecnt++;
return t-noncelen;
}
int main(int argc, char* argv[])
{
int rc, mode;
mode = FIPS_mode();
if(mode == 0)
{
rc = FIPS_mode_set(1);
if(rc == 0) {
cout Failed to enable FIPS mode, ;
cout error: ERR_get_error() endl;
} else {
cout Enabled FIPS mode endl;
}
}
else
{
cout Already in FIPS mode endl;
}
DRBG_CTX *dctx;
dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF);
unsigned char entropytmp[] =
{
0x36, 0x40, 0x19, 0x40, 0xfa, 0x8b, 0x1f, 0xba,
0x91, 0xa1, 0x66, 0x1f, 0x21, 0x1d, 0x78, 0xa0,
0xb9, 0x38, 0x9a, 0x74, 0xe5, 0xbc, 0xcf, 0xec,
0xe8, 0xd7, 0x66, 0xaf, 0x1a, 0x6d, 0x3b, 0x14
};
unsigned char noncetmp[] =
{
0x49, 0x6f, 0x25, 0xb0, 0xf1, 0x30, 0x1b, 0x4f,
0x50, 0x1b, 0xe3, 0x03, 0x80, 0xa1, 0x37, 0xeb
};
/* AES-256 use df PR */
std::cout FIPS_drbg_get_strength(dctx)
FIPS_rand_strength() std::endl;
//if (!FIPS_drbg_set_callbacks(dctx, drbg_test_entropy, 0, 0x10,
drbg_test_nonce, 0))
if (!FIPS_drbg_set_callbacks(dctx, test_entropy, 0, 0, test_nonce,
0))
{
std::cout dupa std::endl;
}
//memcpy(entropy_x, entropytmp, sizeof(entropy_x));
// memcpy(nonce, noncetmp, sizeof(nonce));
TEST_ENT t;
FIPS_drbg_set_app_data(dctx, t);
t.ent = entropytmp;
t.entlen = sizeof(entropytmp);
t.nonce = noncetmp;
t.noncelen = sizeof(noncetmp);
t.entcnt = 0;
t.noncecnt = 0;
//FIPS_drbg_instantiate(dctx, pers, sizeof(pers));
if (!FIPS_drbg_instantiate(dctx, NULL, 0))
{
ERR_load_crypto_strings();
ERR_print_errors(BIO_new_fp(stderr,BIO_NOCLOSE));
}
size_t outlen = 32;
unsigned char outbuf[outlen];
if(!FIPS_drbg_generate(dctx, outbuf, outlen, 0, NULL, 0))
{
ERR_load_crypto_strings();
ERR_print_errors(BIO_new_fp(stderr,BIO_NOCLOSE));
}
FIPS_drbg_uninstantiate(dctx);
FIPS_drbg_free(dctx);
return 0;
* }
Dnia 2015-02-26, czw o godzinie 16:43 +, Dr. Stephen Henson pisze:
On Thu, Feb 26, 2015, Piotr ??obacz wrote:
Yes,
i have read that RAND API will use CTR_DRBG by default but what if i
want to have set seed and than calculate and have the same results on
two different machines? As far as i understand if i set seed - which is
calculated from entropy, nonce and personal string - if it is given i
should get some deterministic value of returned buffer and RAND_bytes
doesn't give me such result it is always different. Correct me if i am
wrong.
OK, can you give some details of how you are instantiating the DRBG?
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
Piotr Łobacz
Biuro Systemów i Oprogramowania
RADMOR S.A.
tel. (58) 6996 929
e-mail: piotr.lob...@radmor.com.pl
www.radmor.com.pl
RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia
NIP: 586-010-21-39
REGON: 190432077
KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku)
Kapitał zakładowy wpłacony: 9 282 830 PLN
___
openssl-users mailing list
To unsubscribe:
Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
I think it was clear enough: NIST/NSA/CMVP is demanding that OpenSSL change the definition of*already* validated platforms before they will allow OpenSSL to addnew platforms. But changing those definitions would invalidate existing governmentcontracts for delivery of products that used the OpenSSL FIPS moduleon those platforms, so the users that actually need the FIPS validationwill be hurt either way. For example, if company X has an existing contract where they promisethat the foo system they delivered to some US Government agencyuses only crypto code which was validated for Red Hat EnterpriseLinux 7.0 (x86_64) running on VmWare ESX, then if OpenSSL obeysthe demand to change the definition to read Red Hat EnterpriseLinux 7.0 (x86_64) running on VmWare ESX 5.1, then company Xwould suddenly be unable to fulfill their contract, which may evenbe a criminal offense. But if OpenSSL refuses to change the definition, OpenSSL cannot deliver to company X a new validationfor Apple OS/X 10.8 (x86_64) running on raw Apple hardware,so company X cannot get a new government contract to deliver forthat platform, and neither can anybody else. So currently, OpenSSL's realistic options are: A. Wait for someone to convince the US Government to drop thisretroactive requirement. B. Start over with a new validation for a new FIPS module version 3, whichwould have to be modified to meet other new demands, whichdidn't exist when FIPS module version 2 was originally submitted. This would involve 2 variants of the FIPS interface code in OpenSSL1.0.3, lots of new code and a very very expensive bill to get thecode validated all over again. On 27/02/2015 03:24, Jeffrey Walton wrote: Hi Steve, I read the 'The FIPS 140-2 Hostage Issue' page. Its not clear to me what the problem is, or how OpenSSL is a hostage. I was looking under The New Requirement for a statement of the problem (assuming the new requirement is causing the problem), but its escaping me (forgive my ignorance). I think the The New Requirement section is bogged down with some background information, which is masking out the statement being made about the problem. If its ... the change that is being demanded is that we supply explicit version numbers for the hypervisor based platforms, so for instance an existing platform, then why is that a problem? How is virtualization a problem? (I know real problems exist in virtualized environments, so PRNGs can suffer. We had one appliance vendor tell us to do the link /dev/random to /dev/urandom trick (sigh...)). Can't that be worked around by having vendors provide real iron? (Most validated platforms appear to be real iron, so it seems nothing has changed to me). Is it a problem on mobile platforms? How is it holding OpenSSL hostage? Can you provide the executive summary here? Jeff On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess marqu...@openssl.com wrote: As always, if you don't know or care what FIPS 140-2 is count yourself very, very lucky and move on. The open source based OpenSSL FIPS module validations now date back over a decade, a period during which we've encountered many challenges. We have recently hit an issue that is apparently inconsequential on its face, but which threatens to bring an end to the era of the open source validated module. This is a situation that reminds me of the old for want of a nail... ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail). Tedious details can be found here: http://openssl.com/fips/hostage.html The short take is that for now at least the OpenSSL FIPS Object Module v2.0, certificate #1747, can no longer be updated to include new platforms. This development also wrecks the already marginal economics of tentative plans for a new open source based validation to succeed the current #1747. So, the #1747 validation may be the last of the collaborative open source FIPS modules. If you are a stakeholder currently using the OpenSSL FIPS module, or with a desire to use it or successor modules (either directly or as the basis for a private label validation), this is the time to speak up. Feel free to contact me directly for specific suggestions or to coordinate with other stakeholders. -Steve M. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl_tpm_engine - create_tpm_key failed when tried to wrap key
*Problem*
We are trying to wrap a private key using storage root key using the
create_tpm_key tool which is part of openssl tpm engine. But it is
failing. We tried to debug this in multiple ways, but not able to
understand what is wrong*. * We are trying to wrap using Storage root key.
Input private key is a 2048 bit length RSA key without any passphrase. The
failure seems to related to getting public key of SRK from the SRK handle
loaded.
*Command Executed:*
# create_tpm_key -w private.pem rsmpvtkey.blob
SRK Password:
### result=12
create_tpm_key.c:444 Tspi_Key_WrapKey result: 0xc (Invalid keyhandle)
*TPM trousers code:*
File: tspi/tspi_key.c
Function : Tspi_Key_GetPubKey
if ((result = TCS_API(tspContext)-GetPubKey(tspContext,
tcsKeyHandle, pAuth,
pulPubKeyLength,
prgbPubKey)))
{
printf(\n ###
result=%d\n,result);
return result; // returns value 12
}
*Version details:*
trousers-0.3.13
openssl_tpm_engine-0.4.2
tpm-tools-1.3.8
*tpm version*
TPM 1.2 Version Info:
Chip Version:1.2.3.16
Spec Level: 2
Errata Revision: 2
TPM Vendor ID: IFX
Vendor Specific data: 031a 00
TPM Version: 0101
Thanks and Regards
Zakkir
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
On Thu, Feb 26, 2015, Piotr ??obacz wrote: Yes, i have read that RAND API will use CTR_DRBG by default but what if i want to have set seed and than calculate and have the same results on two different machines? As far as i understand if i set seed - which is calculated from entropy, nonce and personal string - if it is given i should get some deterministic value of returned buffer and RAND_bytes doesn't give me such result it is always different. Correct me if i am wrong. OK, can you give some details of how you are instantiating the DRBG? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
Thanks, that makes things a lot clearer for me. Not sure what we will do. Isaac -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Steve Marquess Sent: Donnerstag, 26. Februar 2015 14:18 To: openssl-users@openssl.org Subject: Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module? On 02/26/2015 07:04 AM, Isaac Hailperin wrote: Steve, thank you for alerting us. Do I understand correctly that by platform, not a general OS (like Linux, Solaris) on a specific hardware (sparc, x86, ...) is meant, but a very specific distribution release, like Ubuntu 14.04, or CentOS 7.0, on e.g. x86? This would mean that there would be no fips compliant openssl build possible on e.g. a future CentOS 8.1? Note the pedantically correct term is FIPS 140-2 validated, not FIPS compliant. But yes, correct. We are currently using the fips module on Solaris 10, and have plans to use it on Linux, probably RHEL 7.X, but depending on the time in the future, that could well be RHEL 8.X. Platform -- technically Operational Environment or OE -- is a rather peculiar concept in the context of FIPS 140-2 validations, and unfortunately one that has never been clearly defined (also one that changes over time due to ever shifting CMPV guidance). Based on observation and the conventional wisdom of the FIPS validation community, I'll attempt an oversimplified, unofficial, non-authoritative, non-definitive, and thoroughly worthless definition: For Level 1 validations, very roughly speaking, an OE is an operating system name (e.g. Ubuntu) and the first two dot-rev levels of the version number (e.g. 14.04 for 14.04.01, 14.04.02, etc.), *and* a processor architecture. All x86-64 processors with AES-NI (again roughly speaking) are the same processor architecture, as are all those without (and ditto for ARMv7 and NEON). 32 and 64 code comprise separate platforms, and a given OS+OS version+processor architecture+address bit length platform running bare-iron constitutes a different platform from the exact same software+hardware combination running virtualized under each distinct brand name and version of hypervisor environment. So for instance Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.1 is a different platform from Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.5 I've left out a number of known exceptions, complications, and anomalies... -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
On 02/26/2015 07:04 AM, Isaac Hailperin wrote: Steve, thank you for alerting us. Do I understand correctly that by platform, not a general OS (like Linux, Solaris) on a specific hardware (sparc, x86, ...) is meant, but a very specific distribution release, like Ubuntu 14.04, or CentOS 7.0, on e.g. x86? This would mean that there would be no fips compliant openssl build possible on e.g. a future CentOS 8.1? Note the pedantically correct term is FIPS 140-2 validated, not FIPS compliant. But yes, correct. We are currently using the fips module on Solaris 10, and have plans to use it on Linux, probably RHEL 7.X, but depending on the time in the future, that could well be RHEL 8.X. Platform -- technically Operational Environment or OE -- is a rather peculiar concept in the context of FIPS 140-2 validations, and unfortunately one that has never been clearly defined (also one that changes over time due to ever shifting CMPV guidance). Based on observation and the conventional wisdom of the FIPS validation community, I'll attempt an oversimplified, unofficial, non-authoritative, non-definitive, and thoroughly worthless definition: For Level 1 validations, very roughly speaking, an OE is an operating system name (e.g. Ubuntu) and the first two dot-rev levels of the version number (e.g. 14.04 for 14.04.01, 14.04.02, etc.), *and* a processor architecture. All x86-64 processors with AES-NI (again roughly speaking) are the same processor architecture, as are all those without (and ditto for ARMv7 and NEON). 32 and 64 code comprise separate platforms, and a given OS+OS version+processor architecture+address bit length platform running bare-iron constitutes a different platform from the exact same software+hardware combination running virtualized under each distinct brand name and version of hypervisor environment. So for instance Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.1 is a different platform from Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.5 I've left out a number of known exceptions, complications, and anomalies... -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
On Thu, Feb 26, 2015, Piotr ??obacz wrote: Hello, i have a question about FIPS CTR_DRBG. I have managed to compile openssl with fips and everything works fine. The method FIPS_mode returns me 1 so i am in FIPS mode, but what is my problem i dunno how to use properly FIPS_drbg api. If you simply want to use the DRBG in CTR mode then you don't need to do anything special: in FIPS mode the DRBG in CTR mode with a 256 bit AES key is the default and you can just use the normal RAND APIs. Do not use the self test or algorithm test code in applications: you need to set up proper entropy gathering callbacks and the test code contains deterministic examples which would have zero security in a real application. That's what the RAND API will do by default. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Fips CTR_DRBG
Hello,
i have a question about FIPS CTR_DRBG. I have managed to compile openssl
with fips and everything works fine. The method FIPS_mode returns me 1
so i am in FIPS mode, but what is my problem i dunno how to use properly
FIPS_drbg api. I have managed to create new DRBG context and than i
should instantiate it and here are the ladders showing up, because i
need to call FIPS_drbg_set_callbacks. According to file
openssl-fips-2.0.9/fips/rand/fips_drbg_selftest.c i have created those 2
functions:
static size_t test_entropy(DRBG_CTX *dctx, unsigned char **pout,
int entropy, size_t min_len, size_t
max_len)
{
TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
*pout = (unsigned char *)t-ent;
t-entcnt++;
return t-entlen;
}
static size_t test_nonce(DRBG_CTX *dctx, unsigned char **pout,
int entropy, size_t min_len, size_t
max_len)
{
TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
*pout = (unsigned char *)t-nonce;
t-noncecnt++;
return t-noncelen;
}
and entropy and nonce is being set properly but the result is different
than the one in NIST test vectors. Iam trying to check this one:
[AES-256 use df]
[PredictionResistance = False]
[EntropyInputLen = 256]
[NonceLen = 128]
[PersonalizationStringLen = 0]
[AdditionalInputLen = 0]
[ReturnedBitsLen = 512]
COUNT = 0
EntropyInput =
36401940fa8b1fba91a1661f211d78a0b9389a74e5bccfece8d766af1a6d3b14
Nonce = 496f25b0f1301b4f501be30380a137eb
PersonalizationString =
** INSTANTIATE:
Key = 3363d9000e6db47c16d3fc65f2872c08a35f99b2d174afa537a66ec153052d98
V = 9ee8d2e9c618ccbb8e66b5eb5333dce1
AdditionalInput =
** GENERATE (FIRST CALL):
Key = b1dff09c816af6d4b2111fe63c4507cb196154f8c59957a94a2b641a7c16cc01
V = 69eec01b2dd4ff3aab5fac9467f54485
AdditionalInput =
ReturnedBits =
5862eb38bd558dd978a696e6df164782ddd887e7e9a6c9f3f1fbafb78941b535a64912dfd224c6dc7454e5250b3d97165e16260c2faf1cc7735cb75fb4f07e1d
mine Returned bits are
0a84276ebca04933c92bb9f565dd91819e656009b4d9327edc5c777ee2e05a27d9bfd26ab7a0bf2c689ee358d2982de1b1dff09c816af6d4b2111fe63c4507cb
I would be pleased if somebody could point me what am i doing wrong...
--
Piotr Łobacz
Biuro Systemów i Oprogramowania
RADMOR S.A.
tel. (58) 6996 929
e-mail: piotr.lob...@radmor.com.pl
www.radmor.com.pl
RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia
NIP: 586-010-21-39
REGON: 190432077
KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku)
Kapitał zakładowy wpłacony: 9 282 830 PLN
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
Yes, i have read that RAND API will use CTR_DRBG by default but what if i want to have set seed and than calculate and have the same results on two different machines? As far as i understand if i set seed - which is calculated from entropy, nonce and personal string - if it is given i should get some deterministic value of returned buffer and RAND_bytes doesn't give me such result it is always different. Correct me if i am wrong. Dnia 2015-02-26, czw o godzinie 13:28 +, Dr. Stephen Henson pisze: On Thu, Feb 26, 2015, Piotr ??obacz wrote: Hello, i have a question about FIPS CTR_DRBG. I have managed to compile openssl with fips and everything works fine. The method FIPS_mode returns me 1 so i am in FIPS mode, but what is my problem i dunno how to use properly FIPS_drbg api. If you simply want to use the DRBG in CTR mode then you don't need to do anything special: in FIPS mode the DRBG in CTR mode with a 256 bit AES key is the default and you can just use the normal RAND APIs. Do not use the self test or algorithm test code in applications: you need to set up proper entropy gathering callbacks and the test code contains deterministic examples which would have zero security in a real application. That's what the RAND API will do by default. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Piotr Łobacz Biuro Systemów i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lob...@radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku) Kapitał zakładowy wpłacony: 9 282 830 PLN ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Integrating openSSL with libuv's event loop
Will somebody please kind enough to answer On Feb 25, 2015 10:57 PM, Devchandra L Meetei dlmee...@gmail.com wrote: Hi lists I am in the process of enabling TLS support on top of libuv. The approach being employed is to feed the data ,received from stream, to a BIO from BIO pair. and write back the data from the BIO read using BIO_read after a call to BIO_pending. Will this read/write cycle drive the SSL handshake? Do we need to explicitly do handshake in case of server? Currently, we do SSL_read to read application data manually by checking if handshake is completed. Is there a better way to do this? is there a way to get notified? All the code run on the event loop thread. The real reason for the mail is that, the approach highlighted above works fine for a single client. But it is unable to handle multiple client. Will somebody please guide me through with what is wrong. In case, anybody want to have a look at the code. It is available at https://github.com/deleisha/libuv-tls -- Warm Regards --Dev OpenPegasus Developer I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did, Steve Jobs ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
Steve, thank you for alerting us. Do I understand correctly that by platform, not a general OS (like Linux, Solaris) on a specific hardware (sparc, x86, ...) is meant, but a very specific distribution release, like Ubuntu 14.04, or CentOS 7.0, on e.g. x86? This would mean that there would be no fips compliant openssl build possible on e.g. a future CentOS 8.1? We are currently using the fips module on Solaris 10, and have plans to use it on Linux, probably RHEL 7.X, but depending on the time in the future, that could well be RHEL 8.X. Isaac -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Steve Marquess Sent: Mittwoch, 25. Februar 2015 15:08 To: openssl-users@openssl.org Subject: [openssl-users] End of the line for the OpenSSL FIPS Object Module? As always, if you don't know or care what FIPS 140-2 is count yourself very, very lucky and move on. The open source based OpenSSL FIPS module validations now date back over a decade, a period during which we've encountered many challenges. We have recently hit an issue that is apparently inconsequential on its face, but which threatens to bring an end to the era of the open source validated module. This is a situation that reminds me of the old for want of a nail... ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail). Tedious details can be found here: http://openssl.com/fips/hostage.html The short take is that for now at least the OpenSSL FIPS Object Module v2.0, certificate #1747, can no longer be updated to include new platforms. This development also wrecks the already marginal economics of tentative plans for a new open source based validation to succeed the current #1747. So, the #1747 validation may be the last of the collaborative open source FIPS modules. If you are a stakeholder currently using the OpenSSL FIPS module, or with a desire to use it or successor modules (either directly or as the basis for a private label validation), this is the time to speak up. Feel free to contact me directly for specific suggestions or to coordinate with other stakeholders. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
Hi Steve, I read the 'The FIPS 140-2 Hostage Issue' page. Its not clear to me what the problem is, or how OpenSSL is a hostage. I was looking under The New Requirement for a statement of the problem (assuming the new requirement is causing the problem), but its escaping me (forgive my ignorance). I think the The New Requirement section is bogged down with some background information, which is masking out the statement being made about the problem. If its ... the change that is being demanded is that we supply explicit version numbers for the hypervisor based platforms, so for instance an existing platform, then why is that a problem? How is virtualization a problem? (I know real problems exist in virtualized environments, so PRNGs can suffer. We had one appliance vendor tell us to do the link /dev/random to /dev/urandom trick (sigh...)). Can't that be worked around by having vendors provide real iron? (Most validated platforms appear to be real iron, so it seems nothing has changed to me). Is it a problem on mobile platforms? How is it holding OpenSSL hostage? Can you provide the executive summary here? Jeff On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess marqu...@openssl.com wrote: As always, if you don't know or care what FIPS 140-2 is count yourself very, very lucky and move on. The open source based OpenSSL FIPS module validations now date back over a decade, a period during which we've encountered many challenges. We have recently hit an issue that is apparently inconsequential on its face, but which threatens to bring an end to the era of the open source validated module. This is a situation that reminds me of the old for want of a nail... ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail). Tedious details can be found here: http://openssl.com/fips/hostage.html The short take is that for now at least the OpenSSL FIPS Object Module v2.0, certificate #1747, can no longer be updated to include new platforms. This development also wrecks the already marginal economics of tentative plans for a new open source based validation to succeed the current #1747. So, the #1747 validation may be the last of the collaborative open source FIPS modules. If you are a stakeholder currently using the OpenSSL FIPS module, or with a desire to use it or successor modules (either directly or as the basis for a private label validation), this is the time to speak up. Feel free to contact me directly for specific suggestions or to coordinate with other stakeholders. -Steve M. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
