Ok. Now switching to openssl-users mailing list, sorry for RT moderators
and OpenSSL developers.
Tamir,
We are not speaking about different things. You either fail to
understand, or fail to explain, and you're constantly using wrong terms.
For example, what you provided is *not* a certificate, it is an RSA
private key. That's absolutely not the same thing.
In this private key, exponent1, exponent2 and coefficient are encoded
with different lengths because they *are* of different lengths. Is there
anything somewhere preventing these numbers to be of different lengths?
In other terms, is there any formal document stating that these elements
MUST be of equal lengths?
I haven't paid for the ISO8825 document, but I have its free ITU-T
version, X.690 (it's the same text). Below is paragraph 8.3 if this
standard:
-----
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.
-----
Where in this text is said that a sequence of integers must be encoded
with the same length?
Could you take your provided example of a badly encoded key and provide
a representation of what would be a good encoding, clearly?
My guess is that you would like to have an additional leading 00 octet
in exponent2' serialization. That would give the following encoding:
02 41 00 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
Am I right? If my guess is correct, then you need to re-read the 8.3
paragraph again and again. Rule 8.3.2 states that bits of the first
octet and bit 8 of the second octet (of the content octets) can not be
all zero. This example doesn't follow the rule. Your supposedly-bad
provided example does.
Le 03/04/2012 11:34, Tamir Khason via RT a écrit :
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<r...@openssl.org> 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 -+-
--
Erwann ABALEA
-----
PV>Je pense donc qu'un recomptage s'impose.
Oui, numérotez vos neurones. Comme il n'en reste qu'une dizaine,
promettez-moi d'en prendre soin, hein ?
-+- MG in: Guide du Neuneu d'Usenet - Dix points d'un coup -+-
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
