Re: [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE
On 03/23/2012 07:52 AM, Stephen Henson via RT wrote: >> [rouss...@measurement-factory.com - Wed Mar 21 10:24:07 2012]: >> >> >> A verification callback registered with SSL_CTX_set_verify() gets >> called for most validation errors, as expected. The callback always >> returns "1" (keep validating) result so that it can see all errors. >> >> However, after discovering X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE >> error, OpenSSL internal_verify() stops calling the callback due to this >> code in crypto/x509/x509_vfy.c: > The reason for that is that any "errors" after that point are pretty > bogus. You only get that error if the certificate "chain" consists of > one single certificate and it is not self signed. That means its > signature can't be verified and it could contain anything. > > The meaningful errors about being unable to find the issuer will have > been indicated earlier. Hi Steve, Thank you for looking at this issue! If my arguments below do not convince your that a code change is a good idea, please fix the SSL_CTX_set_verify() manual page so that others do not get caught in the same "all errors" trap. IMHO, it is the callback function that should decide what errors are "pretty bogus" and what errors are "meaningful" even though most callbacks will probably not care if most errors are hidden from them for one reason or another. In our rare case, errors such as "expired certificate" are meaningful even if the certificate signature cannot be verified. Please consider reporting all errors to the callback as long as it does no harm. This will minimize the need to re-implement the whole verification function (via SSL_CTX_set_cert_verify_callback) or patching OpenSSL code, both of which are likely to cause problems. Thank you, Alex. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t >= 0
> Andy has made some recent fixes to the AES code too which may be > relevant. Please check the next snapshot to see if you still have problems. I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz To narrow down the problem, I built the "no-asm" version, (which works), saved off the .o files from crypto/sha, then rebuilt with asm enabled. I then replaced the sha object files with the no-asm flavor, edited and rebuilt evp/e_aes_cbc_hmac_sha1.c, (to not use asm), and then linked all that back together... in other words only SHA was non-asm. That worked, which (again) points to the x86_64 sha-1 assembler. Regards, John PS. For what it's worth, here are my CPU details: [ 0.002720] CPU: Physical Processor ID: 0 [ 0.002721] CPU: Processor Core ID: 0 [ 0.002724] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 0.002725] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 0.002727] mce: CPU supports 9 MCE banks [ 0.002737] CPU0: Thermal monitoring enabled (TM1) [ 0.002744] using mwait in idle threads. [ 0.003826] ACPI: Core revision 20120111 [ 0.006109] ftrace: allocating 22586 entries in 89 pages [ 0.016336] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.026335] CPU0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz stepping 07 [ 0.127985] Performance Events: PEBS fmt1+, SandyBridge events, Intel PMU driver. [ 0.127989] PEBS disabled due to CPU errata. [ 0.127991] ... version: 3 [ 0.127991] ... bit width: 48 [ 0.127992] ... generic registers: 8 [ 0.127993] ... value mask: [ 0.127994] ... max period: 7fff [ 0.127995] ... fixed-purpose events: 3 [ 0.127996] ... event mask: 000700ff [ 0.128088] NMI watchdog enabled, takes one hw-pmu counter. [ 0.128142] Booting Node 0, Processors #1 [ 0.128143] smpboot cpu 1: start_ip = 95000 [ 0.159370] NMI watchdog enabled, takes one hw-pmu counter. [ 0.159433] #2 [ 0.159434] smpboot cpu 2: start_ip = 95000 [ 0.190654] NMI watchdog enabled, takes one hw-pmu counter. [ 0.190714] #3 Ok. [ 0.190715] smpboot cpu 3: start_ip = 95000 [ 0.221937] NMI watchdog enabled, takes one hw-pmu counter. [ 0.221962] Brought up 4 CPUs [ 0.221964] Total of 4 processors activated (24741.86 BogoMIPS). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer
On 3 Apr 2012, at 2:34 AM, Tamir Khason via RT wrote: > It seemed that we are speaking about different things. > In certificate i pasted, integers used for exponent1, exponent2 and > coefficient encoded with different lengths. Yes. This is OK. In fact, it is required by DER (ISO 8825, etc). > In chapter 8.3 of ISO 8825 > there is clear statement of how integer values should be encoded. All > need is to take those numbers from "bad" certificate i pasted and > encode it by using different 8825 implementations to see leading zeros > appear. When openssl encode those number leading zeros are missing. > This is what i claim as a bug. If two implementations DER-encode the same integer into different byte sequences, then there is definitely a bug, since the purpose of DER is to be unique (there should be only one possible DER encoding of a value). However, I do not see an example of this. The good/bad example you posted is confusing because they are different keys, with different coefficients, so I am not sure what you think is wrong with the "bad" example. Could you please post a "bad" example generated by OpenSSL, and explain what you think the correct encoding of it is? Here is how the shorter exponent is encoded in the private key you put on pastebin: 02 # universal, primitive, INTEGER 40 # Length = 0x40 bytes 00 80 5b 5f bb 0a c1 c7 a9# value of integer This is the only valid way to DER-encode this integer. If the "00" at the beginning of value were removed, it would change the meaning (the integer would be negative). If another "00" were added, it would be valid BER (I think?), but not valid DER. Paragraph 8.3.2 in the text posted by Peter Sylvester is the rule. A simpler way to think about it is "it is invalid to use any unnecessary 00 bytes". __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
On 04/03/2012 11:34 AM, Tamir Khason via RT wrote: > It seemed that we are speaking about different things. > In certificate i pasted, integers used for exponent1, exponent2 and > coefficient encoded with different lengths. In chapter 8.3 of ISO 8825 > there is clear statement of how integer values should be encoded. All > need is to take those numbers from "bad" certificate i pasted and > encode it by using different 8825 implementations to see leading zeros > appear. When openssl encode those number leading zeros are missing. > This is what i claim as a bug. see 8.3.2 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. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2783] AutoReply: OCSP_parse_url() does not parse URLs containing IPv6 addresses correctly
I've realised that my proposed patch doesn't strip out the square brackets from the host. It probably needs to do that too. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2783] OCSP_parse_url() does not parse URLs containing IPv6 addresses correctly
This bug is present in OpenSSL 1.0.1 and all previous version which I
have looked at
Example of bug:
> openssl ocsp -issuer tom-ca_root_cert.pem -nonce -CAfile
tom-ca_root_cert.pem -url
http://[2001:420:40ff:ffe0:bca9:7919:9219:86b6]:88 -cert
user_signed_cert.pem
Error connecting BIO
Error querying OCSP responsder
34574:error:2006A066:BIO routines:BIO_get_host_ip:bad hostname
lookup:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/b_sock.c:140:host=[2001
If the url provided to openssl ocsp contains an IPv6 address (contained
in square brackets as specified in RFC 3986) then the parsing of the URL
fails.
In OCSP_parse_url() the first : after the http:// is incorrectly
assumed to precede the port number. so the host string ends up as
"[2001" and the port string is wrong also.
Proposed patch to crypto\oscp\ocsp_lib.c attached.
223a224,240
>
> p = host;
>
> /* Check if host is enclosed in sqaure brackets indicating an IPv6
> address which will contatin some ':' */
>
> if (host[0] == '[')
> {
> if (p = strchr(host, ']'))
> {
>/* host was IPv6 address encloded in [
> ], move beyond this for rest of parsing (avoiding any ':' which might confuse
> the port parsing)*/
> p++;
> }
> else
> {
> goto parse_err;
> }
> }
226c243
< if ((p = strchr(host, ':')))
---
> if ((p = strchr(p, ':')))
Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer
maybe i am failed to explain myself. DER encoding says how to encode numbers, RSA key elements define what are those number. So integers from RSA key, should be encoded according ANS1 DER encoding, which means should be have either length octets or end-of-contents octets On Mon, Apr 2, 2012 at 6:56 PM, Erwann Abalea via RT wrote: > Tamir, > > What are you talking about? > DER encoding doesn't say anything about how the length of RSA key > elements compare to each others. > > Read X.690 again, and PKCS#1 also. If you still come with the same > conclusion, re-read again, and again, and again. > > Le 02/04/2012 17:09, Tamir Khason via RT a écrit : >> Erwann, Peter >> This is right, but all numbers are integers and should be encodeed >> accordingly. If encoding assuming fixed size integers, it should use >> length octets, if not end-of-contents octets. At least this is how i >> read 8.1 from ASN.1 spec >> (http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf). >> This is why i think there is a bug in ASN.1 encoding of the >> certificate >> > > -- > Erwann ABALEA > - > nosovermiculotracter: interroger > > -- Tamir http://khason.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer
Erwann, Peter
This is right, but all numbers are integers and should be encodeed
accordingly. If encoding assuming fixed size integers, it should use
length octets, if not end-of-contents octets. At least this is how i
read 8.1 from ASN.1 spec
(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).
This is why i think there is a bug in ASN.1 encoding of the
certificate
On Mon, Apr 2, 2012 at 5:48 PM, Erwann Abalea via RT wrote:
> Bonjour,
>
> There's no optimization here.
>
> Consider the following 256bits RSA key components, following the "RSA
> definition".
> p=FD647F21207C128078ED4D815C13BA43
> q=D332E9F0E5D1661C4D16DB92A1B2D00B
> e=10001
>
> You then have n, the modulus, equal to p*q, which is
> "D10C39F80BA51AF15BF8F25B1FE9006A50FEA8845644481BCC5F6870A1C570E1".
> d, the private exponent, is equal to e^-1 mod (p-1)(q-1), so
> "5D8966F6C1DF226B148813890A822B18973B9B7BFEA3A4BC658FB68E312300F1" in
> this case.
> p and q are 128 bits integers, as asked.
>
> exponent1, exponent2 and coefficient are CRT parameters, and are only
> useful to speed up private RSA operations. They're not mandatory, so
> their size is not defined. Consider them as bonus elements, outside the
> scope of RSA definition.
>
> You can do the maths by yourself, exponent1="d mod (p-1)", exponent2="d
> mod (q-1)".
> exponent1=20FEF3270729E0E6E5D850DD6576142D
> exponent2=2FD959273AEA3638333EFA803E2245
>
> There's nothing strange, or invalid, or optimized here.
>
>
> Le 02/04/2012 15:28, Tamir Khason via RT a écrit :
>> Hello, Erwann
>> This is not related to .NET. Integer is not only value, but also size.
>> Both exponents and its coefficients should be the same length
>> (according RSA definition, both integers) so those numbers should be
>> serialized into ASN1_INTEGER. In for some reason, you want to have
>> integer with different size (for me it's wrong, but it might be your
>> decision because of size optimization), you should use variouse size
>> serialization.
>>
>> This is what is this bug about.
>>
>>
>> On Mon, Apr 2, 2012 at 3:52 PM, Erwann Abalea via RT
>> wrote:
>>> Bonjour,
>>>
>>> Le 02/04/2012 13:21, Tamir Khason via RT a écrit :
There is a bug in ASN.1 DER serializer used to generate RSA private
keys. It trims trailing zeros despite the DER specification. Please
see the full info and reproduction steps in my blog
http://khason.net/dev/openssl-bug-or-why-some-private-keys-cannot-be-used-for-net/#comments
>>> You're wrong. You're mixing things, length encoding and value encoding
>>> (as in TLV).
>>>
>>> In DER, there's no "indefinite length" objects, because the purpose of
>>> DER is to have the only one non ambiguous representation of an object.
>>> Since an "indefinite length" (i.e. not known in advance) object can also
>>> be represented by its "definite length" counterpart by rewriting it once
>>> the object length is known, then an "indefinite length" can't be the
>>> only one representation of this object.
>>>
>>> Next, when writing a DER object, its serialization needs to be unique. A
>>> set of rules are applied to enforce this. For integers, these rules tell
>>> us that the lowest number of bytes need to be used, also ensuring that
>>> negative numbers are expressed in 2s complement form (highest bit set to
>>> 1). Therefore, while you can express the number 0x32 as the following
>>> serialization forms all representing the same number:
>>> 32
>>> 0032
>>> 32
>>> only the first representation is a DER one. The others encode the same
>>> value, but with useless leading bytes.
>>>
>>> Negative numbers cannot have a heading 00 octet, because the highest
>>> order bit would then be equal to 0, and the number considered positive.
>>>
>>> Therefore, the number 0x92 can be serialized as:
>>> 92
>>> 0092
>>> 92
>>> only the second form is a DER one. The first has its highest order bit
>>> set to 1, the number considered negative, its value is then -0x6E. The
>>> third form has an unnecessary leading 00 octet.
>>>
>>> Of course, adding trailing 00 octets are forbidden, this would
>>> completely change the encoded number. Like writing "70" is not the same
>>> as writing "7".
>>>
>>> In your "bad" example key, exponent2's length is smaller than
>>> exponent1's and coefficient's ones. They're not guaranteed to be of the
>>> same length. Exponent{1,2} and coefficient are results of calculations
>>> ("d mod (p-1)", "d mod (q-1)", "q^-1 mod p" respectively), and their
>>> magnitude can vary.
>>> Any "a mod b" number cannot be the same size of "b" (consider for
>>> example "2^32+1 mod 2^32", it's not a 32 bits integer).
>>>
>>> If your "bad" key cannot be used in .NET, there's another reason.
>>>
>>> --
>>> Erwann ABALEA
>>> -
>>> podoclaste: casse-pieds
>>>
>>>
>>
>>
>
>
> --
> Erwann ABALEA
> -
> "The most beautiful thing we can experience is the mysterious. It
> is the source of all true art and all science. He to whom this
> emotion is a stranger,
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
On 04/03/2012 11:34 AM, Tamir Khason via RT wrote:
It seemed that we are speaking about different things.
In certificate i pasted, integers used for exponent1, exponent2 and
coefficient encoded with different lengths. In chapter 8.3 of ISO 8825
there is clear statement of how integer values should be encoded. All
need is to take those numbers from "bad" certificate i pasted and
encode it by using different 8825 implementations to see leading zeros
appear. When openssl encode those number leading zeros are missing.
This is what i claim as a bug.
openssl asn1parse and dumpasn1 happily say that there is no error.
Where do you think there are missing zeros?
All encodes number are positive i.e. the encoing have the hi bit 0
none of the encodings has 9 identical bits at the left?
The private exponent starts with 25, thus has hi-bit 0, thus no padding
required in the encoding. You would get 9 bits 0.
<30 82 02 5D>
0 605: SEQUENCE {
<02 01>
41: INTEGER 0
<02 81 81>
7 129: INTEGER
: 00 C0 80 E3 DB CD 8E A2 89 0A 04 97 96 2F 21 11
: 39 02 45 B4 7C FB 1B 94 F8 3F ED AC DD 9B 52 BF
: FC A3 8C B0 EC 49 7F B7 B6 92 88 E2 7F 21 39 75
: 6C 90 55 6B EA C3 09 F5 16 30 44 27 F6 72 92 A0
: A0 2B 19 39 8E C6 18 00 D7 71 F8 A9 72 B1 91 77
: 16 AD DC 8C 38 11 F8 0B 73 4B 74 AE 28 3D 89 46
: 05 10 A8 DC 57 B3 9C 60 E1 29 67 F3 6E 4C 5E BB
: 70 03 76 C7 0F 0F 01 6A 8A 88 59 5B E8 37 B6 E6
: 01
<02 03>
1393: INTEGER 65537
<02 81 80>
144 128: INTEGER
: 25 38 06 56 16 0D 30 D1 AC 15 2D 35 C5 50 F0 62
: 84 54 F3 CB 82 45 57 ED 13 77 21 88 0B 22 D9 A9
: BF F9 50 AF AE 9A 39 EB DB B3 09 8F A8 DD D2 1D
: 36 5E BD A9 BB 21 EE B7 E6 87 16 EE E8 41 FF 3A
: 02 85 57 74 C5 B9 3C 03 8C 6E 88 B8 01 7C C8 E0
: 50 5A 65 EF 2C 26 C7 0B 0F 68 58 37 7F CB DB 4A
: 5D F1 5E 62 31 A6 FD A4 92 DC CF B8 6B CE 7A 12
: 36 73 E8 27 7E 96 74 43 AE 2C FB 81 11 DF 67 BD
<02 41>
275 65: INTEGER
: 00 E9 F5 27 D3 16 F4 E5 86 6F 6D 4F 13 87 C7 37
: 2A A7 E3 7D 3D 80 87 1D 34 E3 D8 57 BC 78 EC 92
: 86 5E A0 11 49 E3 14 AF DC 9D 3A 02 B8 07 BC 6D
: BA DC 81 2F 02 85 19 8C 68 B7 D6 AA E0 56 0B C0
: B7
<02 41>
342 65: INTEGER
: 00 D2 A3 E5 E3 95 27 B7 EB 46 96 A4 CF A7 1E 06
: D8 42 72 B8 07 F6 1D E3 CD 41 60 95 37 8A 99 B0
: 66 34 36 29 F5 8C 9F 39 04 60 30 3B 51 B9 69 B7
: 37 98 A9 B2 68 16 23 DA EF EC 41 C3 79 C2 FD 67
: 07
<02 41>
409 65: INTEGER
: 00 9A 2E 9C 3E 3A E4 CD D6 98 DC 5A BE AE 3E 95
: 96 A0 EA 05 01 61 10 AA 28 CE F7 26 6A E8 EE 4F
: 6A 0A 36 46 EE 80 9E 83 7F 4A 86 8E 80 25 69 02
: 8F A0 FD E9 B3 29 70 3A DE 50 39 42 87 71 6D 71
: 65
<02 40>
476 64: INTEGER
: 00 80 5B 5F BB 4F 28 E4 EA 7A 19 52 55 37 81 14
: AA B3 D3 34 51 A5 A8 91 28 82 AE 58 3F 80 36 27
: 48 20 88 E1 08 C0 A8 46 16 64 86 FF 9E CD 5D 9E
: 48 42 BF 25 F8 47 85 91 E4 A2 13 71 0A C1 C7 A9
<02 41>
542 65: INTEGER
: 00 D0 46 B6 BD 22 92 2A 60 BB 7B C9 42 EB 50 71
: E6 34 AC 33 00 91 2E 5D 44 61 C9 C3 C6 6E 16 55
: 4D 37 77 82 54 06 E5 9F 3B AC 5C 3F 35 0B B4 BD
: 30 14 37 0E F9 43 86 29 DB 0A 14 CF 28 B7 29 4E
: 25
: }
0 warnings, 0 errors.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
It seemed that we are speaking about different things. In certificate i pasted, integers used for exponent1, exponent2 and coefficient encoded with different lengths. In chapter 8.3 of ISO 8825 there is clear statement of how integer values should be encoded. All need is to take those numbers from "bad" certificate i pasted and encode it by using different 8825 implementations to see leading zeros appear. When openssl encode those number leading zeros are missing. This is what i claim as a bug. On Tue, Apr 3, 2012 at 11:58 AM, Erwann Abalea via RT wrote: > Le 03/04/2012 09:38, Tamir Khason via RT a écrit : >> Please see decrypted private key >> http://pastebin.com/DzYLnHZT >> > > Thanks. > You didn't provide information on where you think the error is, > precisely. I'll base my answer on your previous posts. > > You started to say that "the coefficients should be of the same length". > By "coefficient", you mean the CRT parameters (exponent1, exponent2, > coefficient). You didn't provide an authority source to back up this > assertion. In fact, it's false, and has been explained why. There's no > optimization trick, no particular decision, some parameters can be > smaller than others, that happens, and it's not wrong. > > You then talked about end-of-content octets. There's no such octet in > the provided example. And there's no end-of-content octet possible in > the DER representation of an object. End-of-content octets are found > with indefinite length objects, when you don't know in advance the size > of the object you're encoding, but can tell when it ends; think of it as > "streaming", for example. This is allowed with BER only, not DER. > > It was explained to you how an integer is serialized in DER, in order to > be sure that it's the smallest representation of the integer, without > any confusion between negative and positive numbers. In your provided > example, all the CRT parameters have their DER serialization starting > with a leading 00 octet, because the next non 00 octet has its highest > bit equal to 1, and if this leading 00 octet wouldn't be here the > serialized number would have been considered a negative number, which is > not wanted. The fact that exponent1 and coefficient are of the same size > as prime1 and prime2 is a coincidence (see first paragraph of this > answer). And the fact that exponent2 has a smaller size is also a > coincidence. > > Is there anything still not clear? Do you still think OpenSSL has a bug? > If yes, maybe you could consider switching to the openssl-users mailing > list, which should obviously has been done long ago. Just subscribe to > this list, and reply on this other list. It is clear to anybody here > that what you spotted is not a bug in OpenSSL but an incomprehension on > your side. > > Cordialement. > > -- > Erwann ABALEA > - > Ce ne sont que des propositions. Je ne veux pas les faire passer en > force. Je pense que si mes idées doivent être reprises, elles ne > doivent pas passer au vote, pour plusieurs raison : > -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- > > -- Tamir http://khason.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Le 03/04/2012 09:38, Tamir Khason via RT a écrit : > Please see decrypted private key > http://pastebin.com/DzYLnHZT > Thanks. You didn't provide information on where you think the error is, precisely. I'll base my answer on your previous posts. You started to say that "the coefficients should be of the same length". By "coefficient", you mean the CRT parameters (exponent1, exponent2, coefficient). You didn't provide an authority source to back up this assertion. In fact, it's false, and has been explained why. There's no optimization trick, no particular decision, some parameters can be smaller than others, that happens, and it's not wrong. You then talked about end-of-content octets. There's no such octet in the provided example. And there's no end-of-content octet possible in the DER representation of an object. End-of-content octets are found with indefinite length objects, when you don't know in advance the size of the object you're encoding, but can tell when it ends; think of it as "streaming", for example. This is allowed with BER only, not DER. It was explained to you how an integer is serialized in DER, in order to be sure that it's the smallest representation of the integer, without any confusion between negative and positive numbers. In your provided example, all the CRT parameters have their DER serialization starting with a leading 00 octet, because the next non 00 octet has its highest bit equal to 1, and if this leading 00 octet wouldn't be here the serialized number would have been considered a negative number, which is not wanted. The fact that exponent1 and coefficient are of the same size as prime1 and prime2 is a coincidence (see first paragraph of this answer). And the fact that exponent2 has a smaller size is also a coincidence. Is there anything still not clear? Do you still think OpenSSL has a bug? If yes, maybe you could consider switching to the openssl-users mailing list, which should obviously has been done long ago. Just subscribe to this list, and reply on this other list. It is clear to anybody here that what you spotted is not a bug in OpenSSL but an incomprehension on your side. Cordialement. -- Erwann ABALEA - Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Le 03/04/2012 09:38, Tamir Khason via RT a écrit : Please see decrypted private key http://pastebin.com/DzYLnHZT Thanks. You didn't provide information on where you think the error is, precisely. I'll base my answer on your previous posts. You started to say that "the coefficients should be of the same length". By "coefficient", you mean the CRT parameters (exponent1, exponent2, coefficient). You didn't provide an authority source to back up this assertion. In fact, it's false, and has been explained why. There's no optimization trick, no particular decision, some parameters can be smaller than others, that happens, and it's not wrong. You then talked about end-of-content octets. There's no such octet in the provided example. And there's no end-of-content octet possible in the DER representation of an object. End-of-content octets are found with indefinite length objects, when you don't know in advance the size of the object you're encoding, but can tell when it ends; think of it as "streaming", for example. This is allowed with BER only, not DER. It was explained to you how an integer is serialized in DER, in order to be sure that it's the smallest representation of the integer, without any confusion between negative and positive numbers. In your provided example, all the CRT parameters have their DER serialization starting with a leading 00 octet, because the next non 00 octet has its highest bit equal to 1, and if this leading 00 octet wouldn't be here the serialized number would have been considered a negative number, which is not wanted. The fact that exponent1 and coefficient are of the same size as prime1 and prime2 is a coincidence (see first paragraph of this answer). And the fact that exponent2 has a smaller size is also a coincidence. Is there anything still not clear? Do you still think OpenSSL has a bug? If yes, maybe you could consider switching to the openssl-users mailing list, which should obviously has been done long ago. Just subscribe to this list, and reply on this other list. It is clear to anybody here that what you spotted is not a bug in OpenSSL but an incomprehension on your side. Cordialement. -- Erwann ABALEA - Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2782] BUG report: RSA private key serializer
Please see decrypted private key http://pastebin.com/DzYLnHZT On Mon, Apr 2, 2012 at 11:08 PM, Wim Lewis via RT wrote: > > On 2 Apr 2012, at 10:21 AM, Tamir Khason via RT wrote: >> Please see attached good and bad example + plain dump for both > > The attached file was corrupted at some point in the mail ... perhaps you > could put it on your website? I couldn't read the PEM file you posted either > because it was encrypted. > > I looked at your blog post and I agree with other posters that it looks as if > you are misunderstanding the ASN.1 integer format. For example, the "bad > exponent1", which starts with 00:9a:2e:9c:. If you remove the 00 octet, > the resulting number would be a negative number, because ASN.1 INTEGERs are > always signed. But cryptography code does not usually use negative integers, > so it is easy to forget this and wonder why there are extra 00 octets. Many > people have made this mistake (perhaps most people). > > > -- Tamir http://khason.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
