[openssl-users] openssl dgst computes wrong HMAC?
Hi list,
when I use OpenSSL I suspect some funny business going on with the HMAC
computation of openssl dgst command line tool. Consider:
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
But
#include stdio.h
#include stdint.h
#include stdbool.h
#include openssl/hmac.h
#include hexdump.h
int main() {
uint8_t digest[32];
HMAC_CTX hmacCtx;
HMAC_CTX_init(hmacCtx);
HMAC_Init_ex(hmacCtx, \xaa\xbb\xcc, 3, EVP_sha256(), NULL);
HMAC_Update(hmacCtx, foobar, 6);
unsigned int length;
HMAC_Final(hmacCtx, digest, length);
HMAC_CTX_cleanup(hmacCtx);
HexDump(digest, 32);
return 0;
}
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Also, Python:
#!/usr/bin/python3
import Crypto.Hash.HMAC
import Crypto.Hash.SHA256
key = b\xaa\xbb\xcc
data = bfoobar
hmac = Crypto.Hash.HMAC.new(digestmod = Crypto.Hash.SHA256, key = key)
hmac.update(data)
result = hmac.digest()
print(.join(%02x % (c) for c in result))
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Am I using openssl dgst wrong or is it just plain broken?
Regards,
Johannes
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
i is an abbreviation for internal, meaning OpenSSL's internal format. 2 means to. d means DER. b means blob, and refers to a key blob format used by Microsoft. (That's based on the OpenSSL source code; I haven't looked into the actual provenance of this blob format.) It appears the key blob format typically uses the PVK file extension. Lots of things in OpenSSL aren't documented. It's not strange at all - programmers tend to write code first, documentation second (or later). This is true of a great many open-source projects, and many commercial ones as well. If you want something documented, your best bet is to research it in the code and write the documentation yourself. Regarding your second question: EVP_KEY is defined in evp.h, where we see it contains a pointer to one of the specific key types, such as rsa_st. rsa_st is defined in rsa.h, and if we look there we see that it contains all the RSA parameters, so it implicitly contains both the public and private key. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Serj Sent: Tuesday, February 03, 2015 06:22 To: openssl-users@openssl.org Subject: Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY I have found some info and now some questions more clear for me. But still have 2 questions... i2d_ functions write the DER representation of the object into a buffer. d2i_ functions read the DER representation of the object from a buffer and creates the appropriate object in memory. 1. What is b2i_ and i2b_ functions? EVP_PKEY structure can hold public or private key. It's strangely why there is no this info in the official documentation on www.openssl.orghttp://www.openssl.org 2. Can EVP_PKEY structure hold both private and public keys at once? I have some example of code and there is a use of EVP_PKEY in this manner, that's why I am asking. 03.02.2015, 13:21, Serj ra...@yandex.commailto:ra...@yandex.com: Hello. I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_ For example: i2d_PublicKey i2d_PrivateKey d2i_PublicKey d2i_PrivateKey b2i_PublicKey b2i_PrivateKey i2b_PublicKey_bio i2b_PrivateKey_bio I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean? And one more question. In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are: 1. can we save to EVP_PKEY structure public key not private? 2. can we save to EVP_PKEY structure public and private keys at once? For example: EVP_PKEY * pkey; pkey = EVP_PKEY_new(); RSA * rsa; rsa = RSA_generate_key(...) EVP_PKEY_assign_RSA(pkey, rsa); What key or keys will be in pkey after that? -- Best Regards, Serj Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this email as spam. This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
On Tue, Feb 03, 2015, jan.w...@ptb.de wrote:
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
The MSB is effectively a sign bit but the explanation in the standard isn't
very clear. If you take your example of GTS001.pem and do:
openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der
It will parse out the Ecdsa-Sig-Value field and you get:
0:d=0 hl=2 l= 52 cons: SEQUENCE
2:d=1 hl=2 l= 24 prim: INTEGER
:-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
28:d=1 hl=2 l= 24 prim: INTEGER
:-332658917A3B05831D91176C0512CF91C617819E1A7CF14B
Note the two - signs.
Just to show it isn't just OpenSSL: if you use dumpasn1 on the output (sig.der)
you get:
0 52: SEQUENCE {
2 24: INTEGER
: F8 C6 1E 3E 89 D1 D1 C1 E2 BB 7F BD A9 CC 15 F4
: 49 96 31 87 B2 3C 53 35
: Error: Integer has a negative value.
28 24: INTEGER
: CC D9 A7 6E 85 C4 FA 7C E2 6E E8 93 FA ED 30 6E
: 39 E8 7E 61 E5 83 0E B5
: Error: Integer has a negative value.
: }
From your quote:
The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
What this is saying is that if the MSB is one you subtract that value from
the result.
For example 0x80 without the MSB represents '0' the MSB represents 0x80 and
you subtract that resulting in -0x80. That's why you need the 0 padding byte
prepended if the MSB is one.
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] Windows Embedded Compact 7 OpenSSL
I am trying to get OpenSSL to build for Windows Embebbed Compact 7 using Visual Studio 2008. Is there a write up some wheres that I have missed for doing this? I am having troubles finding much of anything in the way of support for doing this. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 10:00, Johannes Bauer wrote: when I use OpenSSL I suspect some funny business going on with the HMAC computation of openssl dgst command line tool. Consider: Damn, I'm sorry. Forgot to include the version: OpenSSL 1.0.1f 6 Jan 2014 Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl 1.0.2 evp_test core dumps on Sparc T4, solaris 11
I am building openssl 1.0.2 on a number of platforms, and I am having problems on a virtual Solaris 11.0 machine running on a Sparc T4. The code builds fine, but the evp_test core dumps. Here are the last lines of output from the command (test/evp_test test/evptests.txt): Testing cipher id-aes256-CCM(encrypt/decrypt) Key 1b de 32 51 d4 1a 8b 5e a0 13 c1 95 ae 12 8b 21 0010 8b 3e 03 06 37 63 57 07 7e f1 c1 c7 85 48 b9 2e IV 5b 8e 40 74 6f 6b 98 e0 0f 1d 13 ff 41 Plaintext 53 bd 72 a9 70 89 e3 12 42 2b f7 2e 24 23 77 b3 0010 c6 ee 3e 20 75 38 9b 99 9c 4e f7 f2 8b d2 b8 0a Ciphertext 9a 5f cc cd b4 cf 04 e7 29 3d 27 75 cc 76 a4 88 0010 f0 42 38 2d 94 9b 43 b7 d6 bb 2b 98 64 78 67 26 AAD c1 7a 32 51 4e b6 10 3f 32 49 e0 76 d4 c8 71 dc 0010 97 e0 4b 28 66 99 e5 44 91 dc 18 f6 d7 34 d4 c0 Tag 20 24 93 1d 73 bc a4 80 c2 4a 24 ec e6 b6 c2 bf zsh: segmentation fault (core dumped) ./test/evp_test test/evptests.txt pstack: sol11b% pstack core core 'core' of 19831: ./test/evp_test test/evptests.txt 0b80 (6bb20, ffbfec80, ffbfd240, 20, b80, 1) ff20c3c4 aes_ccm_cipher (ffbfe240, ffbfd240, ffbfec80, 20, ff20c220, ff2d8894) + 1a4 ff205e90 EVP_EncryptUpdate (ffbfe240, ffbfd240, ffbfd22c, ffbfec80, 20, 1) + 110 00011afc test1(ff2d8894, ffbfec24, ec00, ffbfe2d0, d, 0) + 33c 00012ed8 main (ffbfe394, e76c, , ffbfe398, e768, e794) + 658 0001161c _start (0, 0, 0, 0, 0, 0) + 5c If I comment out the aes-256-ccm line in evptests.txt, all other tests run fine. When I run the same binary on a virtual machine on a Sparc T2, it works fine. I also tried building the code on the T2, but it still fails on the T4. ldd on evp_test shows that it is using the correct 1.0.2 versions of libssl.so and libcrypto.so. I also tried with the openssl-1.0.2-stable-SNAP-20150202 snapshot but got the same result. Anyone had similar problems? Göran Hammarbäck ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl dgst computes wrong HMAC?
Hi list,
when I use OpenSSL I suspect some funny business going on with the HMAC
computation of openssl dgst command line tool. Consider:
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
But
#include stdio.h
#include stdint.h
#include stdbool.h
#include openssl/hmac.h
#include hexdump.h
int main() {
uint8_t digest[32];
HMAC_CTX hmacCtx;
HMAC_CTX_init(hmacCtx);
HMAC_Init_ex(hmacCtx, \xaa\xbb\xcc, 3, EVP_sha256(), NULL);
HMAC_Update(hmacCtx, foobar, 6);
unsigned int length;
HMAC_Final(hmacCtx, digest, length);
HMAC_CTX_cleanup(hmacCtx);
HexDump(digest, 32);
return 0;
}
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Also, Python:
#!/usr/bin/python3
import Crypto.Hash.HMAC
import Crypto.Hash.SHA256
key = b\xaa\xbb\xcc
data = bfoobar
hmac = Crypto.Hash.HMAC.new(digestmod = Crypto.Hash.SHA256, key = key)
hmac.update(data)
result = hmac.digest()
print(.join(%02x % (c) for c in result))
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Am I using openssl dgst wrong or is it just plain broken?
Regards,
Johannes
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 10:00, Johannes Bauer wrote: when I use OpenSSL I suspect some funny business going on with the HMAC computation of openssl dgst command line tool. Consider: Damn, I'm sorry. Forgot to include the version: OpenSSL 1.0.1f 6 Jan 2014 Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Certificate verification fails with latest commits (ECDSA)
Hi,
we have noticed that with the latest Debian wheezy-security update of the
libssl1.0.0 package sudenly the verification of some of our ECDSA-signed
certificates failed.
I've looked into this and I've traced it down to the following patch
https://github.com/openssl/openssl/commit/684400ce192dac51df3d3e92b61830a6ef90be3e
which introduces a new statement to check the length of the DER-coded
signature in ecs_vrf.c:
- if (d2i_ECDSA_SIG(s, sigbuf, sig_len) == NULL) goto err;
+ if (d2i_ECDSA_SIG(s, p, sig_len) == NULL) goto err;
+ /* Ensure signature uses DER and doesn't have trailing garbage */
+ derlen = i2d_ECDSA_SIG(s, der);
+ if (derlen != sig_len || memcmp(sigbuf, der, derlen))
+ goto err;
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
So my question is: Would you agree that this is an openssl bug or is the
padding byte indeed mandatory and we have to adapt the encoding of our
certificates?
I am attaching one of the certificates for which the verification fails
along with the root ca's certificate.
Cheers,
Jan
X.690 INTEGER:
8.3 Encoding of an integer value
8.3.1 The encoding of an integer value shall be primitive. The contents
octets shall consist of one or more octets.
8.3.2 If the contents octets of an integer value encoding consist of more
than one octet, then the bits of the first
octet and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE ? These rules ensure that an integer value is always encoded in the
smallest possible number of octets.
8.3.3 The contents octets shall be a two's complement binary number equal
to the integer value, and consisting of
bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second
octet, followed by bits 8 to 1 of each octet in turn up to
and including the last octet of the contents octets.
NOTE ? The value of a two's complement binary number is derived by
numbering the bits in the contents octets, starting with bit
1 of the last octet as bit zero and ending the numbering with bit 8 of the
first octet. Each bit is assigned a numerical value of 2N,
where N is its position in the above numbering sequence. The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
Jan Weil
Physikalisch-Technische Bundesanstalt
Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit
Abbestr. 2 - 12
10587 Berlin
Telefon: (+49 30) 34 81 - 77 64
Fax: (+49 30) 34 81 - 69 77 64
Email: jan.w...@ptb.de
GTS001.pem
Description: Binary data
OSM_ROOT.pem
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c This gets posted every once in a while -- google around. Something about the hmac switch not doing what you think it's doing. $ echo -n foobar | openssl dgst -sha256 -mac HMAC -macopt hexkey:aabbcc (stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e BBB ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 11:16, Billy Brumley wrote: $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c This gets posted every once in a while -- google around. Something about the hmac switch not doing what you think it's doing. $ echo -n foobar | openssl dgst -sha256 -mac HMAC -macopt hexkey:aabbcc (stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e Ah, interesting. I did google the issue, but only found post of people who didn't realize that echo without -n appends a newline. If this topic really comes up every now and then, I'd still suggest updating the help page to clarify while remaining identical behavior. Currently it reads -hmac argset the HMAC key to arg. I would suggest -hmac strset the HMAC key to the string str. Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
Hello. I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_ For example: i2d_PublicKey i2d_PrivateKey d2i_PublicKey d2i_PrivateKey b2i_PublicKey b2i_PrivateKey i2b_PublicKey_bio i2b_PrivateKey_bio I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean? And one more question. In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are: 1. can we save to EVP_PKEY structure public key not private? 2. can we save to EVP_PKEY structure public and private keys at once? For example: EVP_PKEY * pkey; pkey = EVP_PKEY_new(); RSA * rsa; rsa = RSA_generate_key(...) EVP_PKEY_assign_RSA(pkey, rsa); What key or keys will be in pkey after that? -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
I have found some info and now some questions more clear for me. But still have 2 questions... i2d_ functions write the DER representation of the object into a buffer.d2i_ functions read the DER representation of the object from a buffer and creates the appropriate object in memory. 1. What is b2i_ and i2b_ functions? EVP_PKEY structure can hold public or private key. It's strangely why there is no this info in the official documentation on www.openssl.org 2. Can EVP_PKEY structure hold both private and public keys at once? I have some example of code and there is a use of EVP_PKEY in this manner, that's why I am asking. 03.02.2015, 13:21, "Serj" ra...@yandex.com: Hello. I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_ For example: i2d_PublicKey i2d_PrivateKey d2i_PublicKey d2i_PrivateKey b2i_PublicKey b2i_PrivateKey i2b_PublicKey_bio i2b_PrivateKey_bio I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean? And one more question. In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are: 1. can we save to EVP_PKEY structure public key not private? 2. can we save to EVP_PKEY structure public and private keys at once? For example: EVP_PKEY * pkey; pkey = EVP_PKEY_new(); RSA * rsa; rsa = RSA_generate_key(...) EVP_PKEY_assign_RSA(pkey, rsa); What key or keys will be in pkey after that? --Best Regards, Serj___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
On Tue, Feb 03, 2015, jan.w...@ptb.de wrote:
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
The MSB is effectively a sign bit but the explanation in the standard isn't
very clear. If you take your example of GTS001.pem and do:
openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der
It will parse out the Ecdsa-Sig-Value field and you get:
0:d=0 hl=2 l= 52 cons: SEQUENCE
2:d=1 hl=2 l= 24 prim: INTEGER
:-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
28:d=1 hl=2 l= 24 prim: INTEGER
:-332658917A3B05831D91176C0512CF91C617819E1A7CF14B
Note the two - signs.
Just to show it isn't just OpenSSL: if you use dumpasn1 on the output (sig.der)
you get:
0 52: SEQUENCE {
2 24: INTEGER
: F8 C6 1E 3E 89 D1 D1 C1 E2 BB 7F BD A9 CC 15 F4
: 49 96 31 87 B2 3C 53 35
: Error: Integer has a negative value.
28 24: INTEGER
: CC D9 A7 6E 85 C4 FA 7C E2 6E E8 93 FA ED 30 6E
: 39 E8 7E 61 E5 83 0E B5
: Error: Integer has a negative value.
: }
From your quote:
The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
What this is saying is that if the MSB is one you subtract that value from
the result.
For example 0x80 without the MSB represents '0' the MSB represents 0x80 and
you subtract that resulting in -0x80. That's why you need the 0 padding byte
prepended if the MSB is one.
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] Support of HMAC-Based ciphersuites (RFC6367) in openssl 1.0.1l
Hello everybody, today i tried to rework the cipher suites of my system and I wanted to integrate the Camellia HMAC-Based ciphersuites from RFC6367, extending TLS v1.2. I tried to find out, which ciphers are supported within the newest openssl version 1.0.1l, but openssl did not have any ciphers of the RFC included, because ./openssl ciphers -v 'CAMELLIA' did only print the following ciphers for SSLv3 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 Is there a special compiler option needed to enable the HMAC ciphersuites, or did I missed to do any configuration? Thanks Best regards, André ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
i is an abbreviation for internal, meaning OpenSSL's internal format. 2 means to. d means DER. b means blob, and refers to a key blob format used by Microsoft. (That's based on the OpenSSL source code; I haven't looked into the actual provenance of this blob format.) It appears the key blob format typically uses the PVK file extension. Lots of things in OpenSSL aren't documented. It's not strange at all - programmers tend to write code first, documentation second (or later). This is true of a great many open-source projects, and many commercial ones as well. If you want something documented, your best bet is to research it in the code and write the documentation yourself. Regarding your second question: EVP_KEY is defined in evp.h, where we see it contains a pointer to one of the specific key types, such as rsa_st. rsa_st is defined in rsa.h, and if we look there we see that it contains all the RSA parameters, so it implicitly contains both the public and private key. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Serj Sent: Tuesday, February 03, 2015 06:22 To: openssl-users@openssl.org Subject: Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY I have found some info and now some questions more clear for me. But still have 2 questions... i2d_ functions write the DER representation of the object into a buffer. d2i_ functions read the DER representation of the object from a buffer and creates the appropriate object in memory. 1. What is b2i_ and i2b_ functions? EVP_PKEY structure can hold public or private key. It's strangely why there is no this info in the official documentation on www.openssl.orghttp://www.openssl.org 2. Can EVP_PKEY structure hold both private and public keys at once? I have some example of code and there is a use of EVP_PKEY in this manner, that's why I am asking. 03.02.2015, 13:21, Serj ra...@yandex.commailto:ra...@yandex.com: Hello. I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_ For example: i2d_PublicKey i2d_PrivateKey d2i_PublicKey d2i_PrivateKey b2i_PublicKey b2i_PrivateKey i2b_PublicKey_bio i2b_PrivateKey_bio I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean? And one more question. In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are: 1. can we save to EVP_PKEY structure public key not private? 2. can we save to EVP_PKEY structure public and private keys at once? For example: EVP_PKEY * pkey; pkey = EVP_PKEY_new(); RSA * rsa; rsa = RSA_generate_key(...) EVP_PKEY_assign_RSA(pkey, rsa); What key or keys will be in pkey after that? -- Best Regards, Serj Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this email as spam. This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
Hi Steve, thanks a lot for your quick response and for the clarification. Von: Dr. Stephen Henson st...@openssl.org The MSB is effectively a sign bit but the explanation in the standard isn't very clear. If you take your example of GTS001.pem and do: openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der It will parse out the Ecdsa-Sig-Value field and you get: 0:d=0 hl=2 l= 52 cons: SEQUENCE 2:d=1 hl=2 l= 24 prim: INTEGER :-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB 28:d=1 hl=2 l= 24 prim: INTEGER :-332658917A3B05831D91176C0512CF91C617819E1A7CF14B Note the two - signs. [...] What this is saying is that if the MSB is one you subtract that value from the result. For example 0x80 without the MSB represents '0' the MSB represents 0x80 and you subtract that resulting in -0x80. Well, yes, that's how two's complement works. That's why you need the 0 padding byte prepended if the MSB is one. The actual problem is that I have totally ignored the mathematics of ECs and it only occured to me when I read your reply that the values of r and s, as far as i understand now, can never be negative. Not so good news for our certificates... Thanks again! Jan Jan Weil Physikalisch-Technische Bundesanstalt Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit Abbestr. 2 - 12 10587 Berlin Telefon: (+49 30) 34 81 - 77 64 Fax: (+49 30) 34 81 - 69 77 64 Email: jan.w...@ptb.de ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL FIPS Object Module 1.* is vulnerable to CVE-2014-3570?
CVE-2014-3570 is fixed in 0.9.8ze. Does the BN_sqr implementation in FIPS Object Module 1.* also need to be fixed? If I run 0.9.8ze on FIPS mode with using FIPS Object Module 1.x, am I vulnerable to the CVE-2014-3570 attacks? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Windows Embedded Compact 7 OpenSSL
I am trying to get OpenSSL to build for Windows Embebbed Compact 7 using Visual Studio 2008. Is there a write up some wheres that I have missed for doing this? I am having troubles finding much of anything in the way of support for doing this. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] The evolution of the 'master' branch
As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will inconvenience people as some applications no longer build. We want to work with maintainers to help them migrate, as we head down this path. We have a wiki page to discuss this effort. It will eventually include tips on migration, application and code updates, and anything else the community finds useful. Please visit: http://wiki.openssl.org/index.php/1.1_API_Changes Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
Hi, Michael. Thank you very much for your answer. Now it's clear. 03.02.2015, 16:08, "Michael Wojcik" michael.woj...@microfocus.com:Lots of things in OpenSSL aren't documented. It's not strange at all - programmers tend to write code first, documentation second (or later). This is true of a great many open-source projects, and many commercial ones as well. If you want something documented, your best bet is to research it in the code and write the documentation yourself. Ok. Will try to write code first, deal with code next time. And after that - questions. I am a beginner in OpenSSL API, that's why I have these questions...I think some simple things because they are already are known by skilled programmers can be asked here via openssl-users@openssl.org. Isn't it?It's too hard to deal with not full documentation. And some help is very necessary at this stage. I think you understand me. "i" is an abbreviation for "internal", meaning OpenSSL's internal format."2" means "to"."d" means "DER"."b" means "blob", and refers to a "key blob" format used by Microsoft. (That's based on the OpenSSL source code; I haven't looked into the actual provenance of this blob format.) It appears the key blob format typically uses the "PVK" file extension. Lots of things in OpenSSL aren't documented. It's not strange at all - programmers tend to write code first, documentation second (or later). This is true of a great many open-source projects, and many commercial ones as well. If you want something documented, your best bet is to research it in the code and write the documentation yourself. Regarding your second question: EVP_KEY is defined in evp.h, where we see it contains a pointer to one of the specific key types, such as rsa_st. rsa_st is defined in rsa.h, and if we look there we see that it contains all the RSA parameters, so it implicitly contains both the public and private key. Michael Wojcik Technology Specialist, Micro Focus --Best Regards, Serj Rakitov ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor. 02.02.2015, 18:04, "Viktor Dukhovni" openssl-us...@dukhovni.org:It should be sufficient for the server to send its close notifywithout waiting for a client response. If the server destroys theSSL connection without calling SSL_shutdown() I am not sure whetherthe session remains cached. I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?Try it, see what happens. The client is certainly free to *try*to the reuse the session, worst-case the server will perform a fullhandshake anyway. Thank you for answers. I will try. --Best Regards, Serj Rakitov ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
