Re: [openssl.org #3203] Normalize PFS key exchange labels
On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org wrote: On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote: I can do whatever you think is most useful, but i need a bit more guidance to be sure i'm giving you what will be most useful for you. I've pulled the update now, thanks. Well I have to admit to being far from a git expert. For me it's best if it's easy to get the patches with commit messages and authorship somewhere I can review them. If I manually have to apply multiple patches and add appropriate credit it's a pain. Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3206] Bug: EVP_PBE_alg_add() registers PBEs with incorrect cipher NIDs
The following bug has been reproduced on RedHat Enterprise Linux with OpenSSL
1.0.1e.
When upgrading from 0.9.8e to 1.0.1e we noticed that a call to PKCS12_parse()
would sometimes fail with the following:
3073869560:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:evp_enc.c:535:
3073869560:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal
error:p12_decr.c:97:
3073869560:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe
crypt error:p12_decr.c:123:
3073869560:error:23076072:PKCS12 routines:PKCS12_parse:parse
error:p12_kiss.c:129:
We determined that the cause was an existing PBE registration within our
application via EVP_PBE_alg_add():
EVP_PBE_alg_add(NID_pbe_WithSHA1And40BitRC2_CBC, EVP_rc2_40_cbc(), EVP_sha1(),
PKCS12_PBE_keyivgen);
Under OpenSSL 1.0.0 and beyond, this causes a PBE to be added with a cipher NID
of RC2-CBC instead of RC2-40-CBC. A change to this API uses an incorrect cipher
NID returned by EVP_CIPHER_type(). The decryption of PKCS12 components that are
encrypted with RC2-40-CBC fails because RC2-CBC is used instead.
Enclosed is a modified version of demos/pkcs12/pkread.c. When linked against
OpenSSL 1.x.x the code will fail to decrypt a PKCS12 file encrypted with
RC2-40-CBC. The same code works fine when linked against 0.9.8*. The code can
be made to work with 1.x.x by removing the call to EVP_PBE_alg_add(), allowing
the builtin version of this PBE (with the correct cipher NID) to be used.
Thank you.
Doug Gibbons | Consulting Engineer | Avaya Inc. | 1300 W. 120th Ave | B3-C61 |
Westminster, CO 80234 | 303-538-3538 |
ldgibb...@avaya.commailto:ldgibb...@avaya.com
/* pkread.c */
#include stdio.h
#include stdlib.h
#include openssl/pem.h
#include openssl/err.h
#include openssl/pkcs12.h
/* Simple PKCS#12 file reader */
int main(int argc, char **argv)
{
FILE *fp;
EVP_PKEY *pkey;
X509 *cert;
STACK_OF(X509) *ca = NULL;
PKCS12 *p12;
int i;
if (argc != 4) {
fprintf(stderr, Usage: pkread p12file password opfile\n);
exit (1);
}
OpenSSL_add_all_algorithms();
ERR_load_crypto_strings();
#if 1
/* With OpenSSL 1.x.x next line creates PBE with incorrect cipher NID */
EVP_PBE_alg_add(NID_pbe_WithSHA1And40BitRC2_CBC, EVP_rc2_40_cbc(),
EVP_sha1(), PKCS12_PBE_keyivgen);
#endif
if (!(fp = fopen(argv[1], rb))) {
fprintf(stderr, Error opening file %s\n, argv[1]);
exit(1);
}
p12 = d2i_PKCS12_fp(fp, NULL);
fclose (fp);
if (!p12) {
fprintf(stderr, Error reading PKCS#12 file\n);
ERR_print_errors_fp(stderr);
exit (1);
}
if (!PKCS12_parse(p12, argv[2], pkey, cert, ca)) {
fprintf(stderr, Error parsing PKCS#12 file\n);
ERR_print_errors_fp(stderr);
exit (1);
}
PKCS12_free(p12);
if (!(fp = fopen(argv[3], w))) {
fprintf(stderr, Error opening file %s\n, argv[1]);
exit(1);
}
if (pkey) {
fprintf(fp, ***Private Key***\n);
PEM_write_PrivateKey(fp, pkey, NULL, NULL, 0, NULL, NULL);
}
if (cert) {
fprintf(fp, ***User Certificate***\n);
PEM_write_X509_AUX(fp, cert);
}
if (ca sk_X509_num(ca)) {
fprintf(fp, ***Other Certificates***\n);
for (i = 0; i sk_X509_num(ca); i++)
PEM_write_X509_AUX(fp, sk_X509_value(ca, i));
}
fclose(fp);
return 0;
}
Re: Safe ECC curves
On Thu, Jan 02, 2014, Salz, Rich wrote: So Curve25519 needs a standard OID and some notes on the format to use for ASN.1. Does such a thing exist? I don't think so. Perhaps the TLS list is the place to discuss this? Should we (I?) start a thread there on a proposal to fit Curve25519 into common TLS usage? Strawman proposal: The keys are OCTET STRING (or does BIGNUM fit better with existing code?) Y is fixed at zero An OID is assigned from the IETF arc Anything else missing? Well ideally it needs to be as close as possible to RFC5280 which is a PKIX document and the group has now closed... great timing. But that ends up with point compression rearing its ugly head. It's not much use though if it takes a glacial time scale to get an OID assigned (or preferably several OIDs AFAICS). I can ask djb but I bet he *really* doesn't care. :) Well if he doesn't that's fine. I'd otherwise feel a bit guilty ats appropriating his curve with an OID. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Safe ECC curves
On 02/01/2014 01:44, Kyle Hamilton wrote: djb has a fixed-clock-cycle algorithm he wrote in GNU assembly for Athlon. I am unhappy with his insistence that nobody should try to implement it for other platforms, as though Athlon is the only platform anyone would ever need. I agree that a platform-independent optimized arithmetic would be a good thing. I would also like to see (since I know nothing about x86, x86_64, or Athlon assembly language) its translation to a 64-bit ABI. But that's out of scope for this list. You might want to look here: https://code.google.com/p/curve25519-donna/ There is also a fully portable C implementation in NaCl (directory crypto_scalarmult/curve25519/ref): http://nacl.cr.yp.to/ Manuel. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Safe ECC curves
On Thu, Jan 02, 2014, Daniel Kahn Gillmor wrote: On 01/02/2014 08:50 AM, Salz, Rich wrote: [Dr. Stephen Henson wrote:] So Curve25519 needs a standard OID and some notes on the format to use for ASN.1. Does such a thing exist? I don't think so. yes, i mentioned it up-thread: https://tools.ietf.org/html/draft-josefsson-tls-curve25519-01 this isn't formalized yet, and it raised discussion that wasn't yet resolved, but it's the document to work from, i think. That's just TLS. To add more complete support to OpenSSL including storing private keys in PEM files and public keys in case we ever use it in ECDH certificates it needs an OID and some details on how the keys are encoded. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Safe ECC curves
On 01/02/2014 12:35 PM, Dr. Stephen Henson wrote: That's just TLS. To add more complete support to OpenSSL including storing private keys in PEM files and public keys in case we ever use it in ECDH certificates it needs an OID and some details on how the keys are encoded. But ECDHE doesn't need any of these trappings, as nice as they would be to have. The curves are known; implementations of them are known; secret keys can be held in memory in any standard way, and public keys can be transmitted on the wire for the key exchange as simply as possible, without specifying PKCS encodings or SPKI or whatever. Getting Curve25519 (and Curve3617?) functional for ECDHE would be a demonstrably good thing on its own, and it would be a shame for that functionality to wait until people could finally agree on how to use PKCS encodings and EdDSA for X.509 certificates. --dkg signature.asc Description: OpenPGP digital signature
Re: Safe ECC curves
On Thu, Jan 02, 2014 at 12:59:39PM -0500, Daniel Kahn Gillmor wrote: On 01/02/2014 12:35 PM, Dr. Stephen Henson wrote: That's just TLS. To add more complete support to OpenSSL including storing private keys in PEM files and public keys in case we ever use it in ECDH certificates it needs an OID and some details on how the keys are encoded. But ECDHE doesn't need any of these trappings, as nice as they would be to have. The curves are known; implementations of them are known; secret keys can be held in memory in any standard way, and public keys can be transmitted on the wire for the key exchange as simply as possible, without specifying PKCS encodings or SPKI or whatever. Getting Curve25519 (and Curve3617?) functional for ECDHE would be a demonstrably good thing on its own, and it would be a shame for that functionality to wait until people could finally agree on how to use PKCS encodings and EdDSA for X.509 certificates. I also think that ECDHE really is currently the priority, to have an alternative to the NIST P curves at least some people think are backdoored by the NSA and as result want to avoid. Most people seem want to do PFS now, but some want ECDHE for speed and the other DHE to avoid the NIST P curves. I think having something like Curve25519 could make both sides agree on using ECDHE. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/02/2014 03:32 PM, Ben Laurie wrote: On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? I read that as well, but I assumed that just meant that he now has access to the changesets in his local copy. I don't think he's applied them to his master branch, or if he has, he hasn't pushed that master branch to the canonical repository. or maybe i'm not looking at the correct repository? i don't see them applied to the master branch at https://github.com/openssl/openssl, and i don't see them at http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be looking somewhere else? --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/02/2014 03:32 PM, Ben Laurie wrote: On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? I read that as well, but I assumed that just meant that he now has access to the changesets in his local copy. I don't think he's applied them to his master branch, or if he has, he hasn't pushed that master branch to the canonical repository. or maybe i'm not looking at the correct repository? i don't see them applied to the master branch at https://github.com/openssl/openssl, and i don't see them at http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be looking somewhere else? --dkg signature.asc Description: PGP signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3203] Normalize PFS key exchange labels
On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote: I don't mean to be impatient -- if it's just a matter of playing catchup over the close of the winter holiday, i can wait :) Yes that's pretty much it. I'll be looking reviewing the patches in the next few days. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2480] ... 3 recipients: generation error
I just encountered this issue with precisely the same error. It appears with all configurations including 'no-des'. 1.0.1e tarball OSX 10.9.1 XCode 5.0.2 # minimal test-case ./Configure no-des make depend make make test — Sent from Mailbox for iPhone __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
