Re: [openssl-users] Using set_serial to control serial number size directly
On 21/08/2017 16:22, Robert Moskowitz wrote: On 08/21/2017 10:03 AM, Salz, Rich wrote: If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. Kind of where my thinking is going. But once I make it '1', it might as well be 1 byte rand! :) Well 1 - 127 random... But no need to make it 20 octets. Just leave it at 8. And yes, I can see some jump on the 'save' 7 bytes bandwagon. Note that while the random bits in the serial number are technically there to defend against attacks on the issuing CA if that CA uses an old/outdated algorithm, the real issue is retaining compatibility with Browsers that blindly assume that certificates are created according to the contractual requirements applied to public CAs such as DigiCert. One of those is 20 bytes max (after DER encoding, thus 159 bits max). Another is at least 64 fresh random bits in each serial number generated by the CA. Another may or may not be 20 bytes min (before DER encoding, thus 153 bits min). Also why I have to work out BER to compare that sizing to DER. Trying to do that today. BER is never shorter than DER. However for internal processing in memory-restricted devices, it may be possible/easy to save space by using a simplified encoding internally, and then convert to DER on the fly when talking to standard software (such as Web Browsers) externally. This will ultimately be a trade off between code size (to do the conversion) and data size (to store the certificate). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
My proposal.
Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a
block cipher operating on blocks of k bits, and operate this block cipher in
CTR mode, with a proper secret key and secret starting counter. That way, no
collision detection is necessary, you’ll be able to generate 2^(k/2) unique k
bits longs serial numbers (in fact, you can generate 2^k unique serial numbers,
but after 2^(k/2) you lose some security guarantees).
With 3DES, k=64, and with AES, k=128.
Since you need to make a tradeoff between security and size, you can play with
lightweight block ciphers such as Simon, Speck, or find some tweakable
lightweight block cipher, maybe from the ECRYPT portfolio (it’s down at this
moment).
Again, the 64bits coming from a CSPRNG is for public CAs only, and the
uniqueness of a serial number is a dirty hack to be able to use a non
collision-resistant hash function a little longer. If you’re confident the hash
function used for signature is collision resistant (for example a member of the
SHA2 or SHA3 family), and you have a purely private CA, don’t bother will all
this, the only hard requirement is the unicity of the tuple {CA name, serial
number}.
Cordialement,
Erwann Abalea
> Le 21 août 2017 à 15:44, Robert Moskowitz a écrit :
>
>
>
> On 08/21/2017 09:36 AM, Salz, Rich wrote:
>> ➢ Thus how large does this random number have
>>
>> It’s also to protect against predicting serial numbers and being able to
>> leverage that. It’s not just (nor really mainly) the MD5 digest attacks.
>> According to CABForum, you need 8 octets. No reason not to use more if you
>> can.
>
> Sure there is. On constrained systems with constrained communication links.
> Every byte counts. My real thrust on this is for IoT. To get IoT developers
> to build around certs and know their products work with them instead of, well
> we will get to it eventually.
>
> When I work with 802.15.4 communications with a 128 byte MTU, there is
> considerable debate over every byte sent. When you tell an IoT chip maker
> that they have to go from 32KB memory to 100MB, they walk out of the room.
>
> Oh, I want DOTS and I2NSF developers to be working with certs from the get
> go, instead waiting for deployments and getting 'production' certs and THEN
> discovering what works and what does not. But IoT is in many ways more of a
> challenge.
>
> So yes, size matters.
>
>>
>>
>> ➢ page was talking about in conjunction with the -CA option. With 'openssl
>> ca' use of the serial file is mandatory according to the man page.
>> There are no command line options for it.
>>
>> Fixed in master and will be part of the next releases; the –rand_serial flag.
>>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 10:03 AM, Salz, Rich wrote: If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. Kind of where my thinking is going. But once I make it '1', it might as well be 1 byte rand! :) Well 1 - 127 random... But no need to make it 20 octets. Just leave it at 8. And yes, I can see some jump on the 'save' 7 bytes bandwagon. Also why I have to work out BER to compare that sizing to DER. Trying to do that today. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 09:36 AM, Salz, Rich wrote: ➢ Thus how large does this random number have It’s also to protect against predicting serial numbers and being able to leverage that. It’s not just (nor really mainly) the MD5 digest attacks. According to CABForum, you need 8 octets. No reason not to use more if you can. Sure there is. On constrained systems with constrained communication links. Every byte counts. My real thrust on this is for IoT. To get IoT developers to build around certs and know their products work with them instead of, well we will get to it eventually. When I work with 802.15.4 communications with a 128 byte MTU, there is considerable debate over every byte sent. When you tell an IoT chip maker that they have to go from 32KB memory to 100MB, they walk out of the room. Oh, I want DOTS and I2NSF developers to be working with certs from the get go, instead waiting for deployments and getting 'production' certs and THEN discovering what works and what does not. But IoT is in many ways more of a challenge. So yes, size matters. ➢ page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Fixed in master and will be part of the next releases; the –rand_serial flag. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
➢ Thus how large does this random number have It’s also to protect against predicting serial numbers and being able to leverage that. It’s not just (nor really mainly) the MD5 digest attacks. According to CABForum, you need 8 octets. No reason not to use more if you can. ➢ page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Fixed in master and will be part of the next releases; the –rand_serial flag. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 09:20 AM, Salz, Rich via openssl-users wrote: But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate. This whole subject is tied into the substitution attack found with using an MD5 hash where you could change some things in the cert and still have a valid cert. The solution, besides dropping MD5, was to include a crypto random number in the beginning of the cert, and the serial was chosen for this sacrifice. Thus how large does this random number have to be to defend against this attack? is 8 octets enough or is 20 needed? This is to make another valid cert with a different keypair. OK, I get this for a cert signed by an issuer. But the root issuer? I don't see the attack. Thus no need to push the root cert's serial to 20 octets. I know I am a little cavalier in describing the attack, but that was the basic point of why to move away from sequential serials to random and what size (though there are other things about CAs that can be discovered by analyzing the sequential serial numbers they used). Meanwhile, I was wrong that -set_serial works with 'openssl ca'. The man page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Using set_serial to control serial number size directly
I have worked out that: openssl req -config openssl-root.cnf -set_serial 0x$(openssl rand -hex 19) -key private/ca.key.pem\ -subj "$DN"\ -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem allows you to override the serial number select process and thus control what size serial number you use. This also works for openssl ca for signing a csr, so you don't have to deal with the serial file. You can further parameterize this with: -set_serial 0x$(openssl rand -hex $sn) when sn=some number 8 to 19. But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. The nature of the attack, just to me, does not seem to apply to a root CA cert. So that a serial number size of 8 octets is just fine for the root cert. Please correct me if I don't have the risk properly understood. thanks Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
