[openssl-users] Call for FIPS 140-2 stakeholders
If you don't know or care about FIPS 140-2 then count yourself very lucky and move on. In the same spirit of collaboration that underlies all of the open source based OpenSSL FIPS Object Module validations, of which the #1747 validation is the latest, some of the stakeholders impacted by the recent hostage issue[*] are discussing possible responses among themselves. I have been told they would like to reach out to other interested impacted customers. We know who some of these are, but there will be many more users of the #1747 validation on those platforms we don't know about. If you are a such a stakeholder and would like to participate in those discussions please let me know (contact info below) and I'll make the appropriate introductions. -Steve M. [*] see http://openssl.com/fips/aftermath.html -- 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] Suggested way to add option to both SSL_CTX* and SSL*?
On Mon, Jun 22, 2015, Salz, Rich wrote:
I looked at how SSL_CTX_set_cipher_list and SSL_set_cipher_list operate,
but they don't use SSL_{CTX}_ctrl.
That API probably predates the ctrl. It's a trade-off; you lose type-safety
but have less to document :)
What is the suggested way to control the functionality through a flag?
Probably the _ctrl API. Problem is we're running out of bits. Let's see
what drH thinks.
We certainly are running out of options bits and will need to do something to
address that at some point it hasn't been decided precisely *what* yet.
However if the option is related to certificates it can use the cert_flags
field in the CERT structure. If it is related to mode then it can use the mode
field. Both of those have plenty to spare.
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] Fast DH parameters generation
Of course, the second approach is a lot faster - however, can anyone explain the warning not from the documentation Be careful to avoid small subgroup attacks when using this. ? AFAIK, for such attacks to be effective, they require that the parameters are re-used multiple times. However, in our specific case, the generated parameters will be used only once (2048 bits) and then discarded... No, small subgroups or confinement attacks are due to Schnorr. They are based on the size of q, not the size of p. See https://en.wikipedia.org/wiki/Small_subgroup_confinement_attack. You can have a large group (2048-bits), but a small subgroup (say 48-bits or 64-bits) that makes the problem much easier. A security level of 48-bits is well within reach of many attackers. 64-bits is within reach of some attackers, given how cheaply compute time can be purchased on Nova or EC2. And also see On Small Subgroup Non-confinement Attack, https://eprint.iacr.org/2010/149.pdf. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] RT was down today, please resend
Hi, due to a mysql screwup, whatever was sent to openssl-b...@openssl.org after 06:00 UTC today was lost (everything before that was safely backed up). If you did send something, I would like to kindly ask you to resend it. Sorry for the inconvenience. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Provisional FIPS 140-2 casualty list
Hi Steve, Forgive my ignorance From the previous postings, I *thought* that the validation only applies to real iron, and [retroactively] was not conferred to the VMs. But it seems like this list includes real hardware, too: 12 Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 32 Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3) 33 Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3) Those caught my eye because I used them in the past (specifically, 12). What exactly changed? Or where is my disconnect? Jeff On Thu, Jun 18, 2015 at 11:17 AM, Steve Marquess marqu...@openssl.com wrote: If you don't know or care what FIPS 140-2 is then count yourself very lucky and move on. I've created a new web page to summarize the current status of the long-running hostage saga: http://openssl.com/fips/aftermath.html If you use the OpenSSL FIPS Object Module 2.0 (validation #1747), you should confirm that any platforms you use that module on are among the survivors. However, don't panic quite yet if you're using one of the deleted platforms. I'm pretty sure that the Big Blob 'o Text list as currently posted has several clerical errors that the CMVP will eventually correct. Also, I expect to receive permission from at least some of the directly impacted platform sponsors to supply information for revised platform descriptions. Once those are up, then you can panic. New developments will be noted in this new web page. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Provisional FIPS 140-2 casualty list
On 06/22/2015 02:36 AM, Jeffrey Walton wrote: Hi Steve, Forgive my ignorance From the previous postings, I *thought* that the validation only applies to real iron, and [retroactively] was not conferred to the VMs. But it seems like this list includes real hardware, too: 12 Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 32 Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3) 33 Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3) Those caught my eye because I used them in the past (specifically, 12). What exactly changed? Or where is my disconnect? CMVP requirements relating to virtualization have evolved considerably over time, and in fact it's the retroactive enforcement of those changing requirements that led to this hostage mess[*]. Once upon a time a virtualized OS+processor was treated the same as that OS running on that processor bare iron, i.e. no virtualization. For instance, AcmeOS 1.2 on x86. At the time the #1747 validation was started the CMVP required that virtualization be noted, as in an OS and a processor architecture running virtualized under some general virtualization environment (e.g. AcmeOS 1.2 under vSphere on x86), but there was no requirement for a hypervisor product version number. Then came a requirement for a hypervisor brand name plus version, e.g. AcmeOS 1.2 under vSphere ESXi 4.4. This last requirement came into force after the #1747 validation was out and already had quite a few platforms. The platforms added since this requirement was introduced have the hypervisor brand name version qualification (e.g. platforms 97, 98). -Steve M. [*] retroactive requirements changes imposed on in-process validation actions have long been common, and are part of the challenge of completing any validation action with any kind of predictable budget or schedule. The imposition of retroactive changes on previously approved validations is a disturbing new development. -- 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] Has the support for SPARC architecture crypto extensions been Implemented?
Hello OpenSSL folks, We have a product which is an OpenSSL 1.0.1 application. One of my customers is running my product on his SunSparc Solaris 11 platform which has a Crypto Accelerator. Around the end of last year, he complained to me that OpenSSL doesn't utilize the accelerator at all. I then checked on OpenSSL website and found the following description. Changes between 1.0.1e and 1.0.2 [xx XXX ] *) Initial support for PowerISA 2.0.7, first implemented in POWER8. This covers AES, SHA256/512 and GHASH. Initial means that most common cases are optimized and there still is room for further improvements. Vector Permutation AES for Altivec is also added. [Andy Polyakov] *) Add support for little-endian ppc64 Linux target. [Marcelo Cerri (IBM)] *) Initial support for AMRv8 ISA crypto extensions. This covers AES, SHA1, SHA256 and GHASH. Initial means that most common cases are optimized and there still is room for further improvements. Both 32- and 64-bit modes are supported. [Andy Polyakov, Ard Biesheuvel (Linaro)] *) Improved ARMv7 NEON support. [Andy Polyakov] *) Support for SPARC Architecture 2011 crypto extensions, first implemented in SPARC T4. This covers AES, DES, Camellia, SHA1, SHA256/512, MD5, GHASH and modular exponentiation. [Andy Polyakov, David Miller] Hence I told him to wait until OpenSSL 1.0.2 to be released officially. I promised him I would upgrade the OpenSSL used in my product to 1.0.2, so his crypto accelerator would be utilized. He came back to me recently as OpenSSL 1.0.2 has been released officially. However after checking change log of 1.0.2, 1.0.2a, 1.0.2b and 1.0.2c, I could not find any description regarding to 'Support for SPARC Architecture 2011 crypto extensions'. My question is if the support for SPARC architecture crypto extensions has been Implemented yet? Thanks in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Has-the-support-for-SPARC-architecture-crypto-extensions-been-Implemented-tp58866.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Has the support for SPARC architecture crypto extensions been Implemented?
Found this, so the feature has been implemented. Aaron Changes between 1.0.1l and 1.0.2 [22 Jan 2015] ... *) Support for SPARC Architecture 2011 crypto extensions, first implemented in SPARC T4. This covers AES, DES, Camellia, SHA1, SHA256/512, MD5, GHASH and modular exponentiation. [Andy Polyakov, David Miller] -- View this message in context: http://openssl.6102.n7.nabble.com/Has-the-support-for-SPARC-architecture-crypto-extensions-been-Implemented-tp58866p58867.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] beginner needs advice on data signature/verification
Response inline below, prefixed with MW. (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Marco Warga Sent: Saturday, June 20, 2015 04:48 To: openssl-users@openssl.org Subject: [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't a very common requirement. It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - is commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. Thanks alot, Marco X509_verify_cert X509_verify_cert Click herehttps://www.mailcontrol.com/sr/SMsSvn1riRfGX2PQPOmvUsrLibhXE7+S86glxWVUEjKk!XLlG9uNumpG1wkqEL+kqdX9II!hjWj1JTd!1uc+!w== to report this email as spam. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How to provide KDF to ECDH key computation when using EVP API?
Hi,
My goal is to implement ECDH in my own engine. The snippet below shows
the struct that needs to be filled and set as the engine's ECDH method:
struct ecdh_method {
const char *name;
int (*compute_key) (void *key, size_t outlen, const EC_POINT *pub_key,
EC_KEY *ecdh, void *(*KDF) (const void *in,
size_t inlen, void *out,
size_t *outlen));
# if 0
int (*init) (EC_KEY *eckey);
int (*finish) (EC_KEY *eckey);
# endif
int flags;
char *app_data;
};
I intend to leverage the KDF mechanism, but it does not seem to be
exposed in the EVP API. Is that possible at all? If yes, how do I do
that? If no, what is the purpose of the KDF() parameter in compute_key?
(By the way, struct ecdh_method is in crypto/ecdh/ech_locl.h, which
seems to be a private header file. Am I supposed/allowed to include it
anyway?)
Thanks in advance,
Reinier
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
