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 <r...@openssl.org> 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<r...@openssl.org> >> 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 >>> 000032 >>> 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 >>> 000092 >>> 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, who can no longer pause to wonder and > stand rapt in awe, is as good as dead: his eyes are closed." > - Albert Einstein > > -- Tamir http://khason.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
