Add ECDSA signature R and S to X509 structure

[Ken Goldman]

I have an ECDSA signature supplied to me as R and S byte arrays and 
lengths (from an HSM).


How do I add them to the X509 structure?

Is there an API, a set of calls, or do you have any hints?

~~

For RSA, I simply filled in the ASN1_BIT_STRING length, data, and flags, 
but an RSA signature is a simply BIT_STRING.


For ECDSA, the BIT_STRING is a SEQUENCE of two INTEGERs.

I could construct the SEQUENCE DER manually and then add it as with RSA, 
but that seems like a hack.  Is there a better way?


Is there a better way for RSA?  I suspect that peering inside the 
ASN1_BIT_STRING will break for openssl 1.1.

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

On 8/16/19 12:34 PM, Erwann Abalea wrote:

Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, 
value=0xff). It may, as a side effect, enlarge the number of octets necessary 
to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL 
keeps them by default).

If size is a hard constraint:
  - you can probably remove the emailProtection EKU (it's an OID, you'll gain 
10 octets). Depending on your use-case, you may need to tweak the EKU (or 
remove it completely).
  - SKI and AKI extensions may not be necessary
  - Key Usage may be marked as non critical (it's a SHOULD in PKIX)


I will look at this and figure out what to change in my .cnf.  I have 
been using what I have in my:


draft-moskowitz-eddsa-pki


A quick reading of RFC8002 tells me that you may need to include the 
IssuerAltName extension as well?


That is the 8002 SHOULD.  But following rfc 2119 on SHOULD, since I can 
calculate the Issuer HHIT from the prefix in issuerName and the Issuer's 
Public Key (not carried in the client cert, got to go up the chain to 
get that), I am avoiding at this stage of development to closely follow 
8002.  Still thinking on all this.


Thank you on your help



Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » 
 a écrit :

 Viktor,
 
 
 On 8/16/19 8:41 AM, Viktor Dukhovni wrote:

 >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:
 >>
 >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"
 > This is wrong.  When the subject DN is empty, the subjectAltName should 
be
 > marked as critical.  IIRC some Java implementations reject the 
certificate
 > otherwise.
 
 I have just created a client cert with empty subjectName and critical

 subjectAltName.  Interestingly, it is 4 bytes larger than the earlier
 non-critical SAN cert.  See below for the output of the cert.
 
 >> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.

 > OpenSSL supports empty (empty RDN sequence) subject DNs.
 > The "-subj /" option is one way to make that happen.
 >
 > Empty is of course different from "absent", which is not
 > possible, since the subject DN is a required component of
 > an X.509 certificate.
 
 I now have it clear that Empty SN is NOT a cert with NO SN.  It is there

 with null content.
 
 Thank you all.
 
 $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem

 Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number:
  c9:8f:b2:7b:e1:95:74:d0
  Signature Algorithm: ED25519
  Issuer: CN = 2001:24:28:14::/64
  Validity
  Not Before: Aug 16 14:54:58 2019 GMT
  Not After : Aug 25 14:54:58 2020 GMT
  Subject:
  Subject Public Key Info:
  Public Key Algorithm: ED25519
  ED25519 Public-Key:
  pub:
  69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
  c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
  4c:a5
  X509v3 extensions:
  X509v3 Basic Constraints:
  CA:FALSE
  Netscape Cert Type:
  SSL Client, S/MIME
  Netscape Comment:
  OpenSSL Generated Client Certificate
  X509v3 Subject Key Identifier:
 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
  X509v3 Authority Key Identifier:
 keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA
 
  X509v3 Key Usage: critical

  Digital Signature, Non Repudiation, Key Encipherment
  X509v3 Extended Key Usage:
  TLS Web Client Authentication, E-mail Protection
  X509v3 Subject Alternative Name: critical
  IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
  Signature Algorithm: ED25519
   01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
   4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
   dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
   ba:1a:b4:17:c0:bb:0f:da:be:02
 
 
 

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, 
value=0xff). It may, as a side effect, enlarge the number of octets necessary 
to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL 
keeps them by default).

If size is a hard constraint:
 - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 
octets). Depending on your use-case, you may need to tweak the EKU (or remove 
it completely).
 - SKI and AKI extensions may not be necessary
 - Key Usage may be marked as non critical (it's a SHOULD in PKIX)

A quick reading of RFC8002 tells me that you may need to include the 
IssuerAltName extension as well?

Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » 
 a écrit :

Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
>> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:
>>
>> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"
> This is wrong.  When the subject DN is empty, the subjectAltName should be
> marked as critical.  IIRC some Java implementations reject the certificate
> otherwise.

I have just created a client cert with empty subjectName and critical 
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier 
non-critical SAN cert.  See below for the output of the cert.

>> I can believe that OpenSSL doesn't support empty subjectName's.  An 
empty one, with no relative disintuished name components, is not the same as 
not present.
> OpenSSL supports empty (empty RDN sequence) subject DNs.
> The "-subj /" option is one way to make that happen.
>
> Empty is of course different from "absent", which is not
> possible, since the subject DN is a required component of
> an X.509 certificate.

I now have it clear that Empty SN is NOT a cert with NO SN.  It is there 
with null content.

Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 c9:8f:b2:7b:e1:95:74:d0
 Signature Algorithm: ED25519
 Issuer: CN = 2001:24:28:14::/64
 Validity
 Not Before: Aug 16 14:54:58 2019 GMT
 Not After : Aug 25 14:54:58 2020 GMT
 Subject:
 Subject Public Key Info:
 Public Key Algorithm: ED25519
 ED25519 Public-Key:
 pub:
 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
 c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
 4c:a5
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Cert Type:
 SSL Client, S/MIME
 Netscape Comment:
 OpenSSL Generated Client Certificate
 X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
 X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

 X509v3 Key Usage: critical
 Digital Signature, Non Repudiation, Key Encipherment
 X509v3 Extended Key Usage:
 TLS Web Client Authentication, E-mail Protection
 X509v3 Subject Alternative Name: critical
 IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
 Signature Algorithm: ED25519
  01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
  4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
  dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
  ba:1a:b4:17:c0:bb:0f:da:be:02

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:

On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark 
subjectAltName as non-critical"

This is wrong.  When the subject DN is empty, the subjectAltName should be
marked as critical.  IIRC some Java implementations reject the certificate
otherwise.


I have just created a client cert with empty subjectName and critical 
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier 
non-critical SAN cert.  See below for the output of the cert.



I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, 
with no relative disintuished name components, is not the same as not present.

OpenSSL supports empty (empty RDN sequence) subject DNs.
The "-subj /" option is one way to make that happen.

Empty is of course different from "absent", which is not
possible, since the subject DN is a required component of
an X.509 certificate.


I now have it clear that Empty SN is NOT a cert with NO SN.  It is there 
with null content.


Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    c9:8f:b2:7b:e1:95:74:d0
    Signature Algorithm: ED25519
    Issuer: CN = 2001:24:28:14::/64
    Validity
    Not Before: Aug 16 14:54:58 2019 GMT
    Not After : Aug 25 14:54:58 2020 GMT
    Subject:
    Subject Public Key Info:
    Public Key Algorithm: ED25519
    ED25519 Public-Key:
    pub:
    69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
    c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
    4c:a5
    X509v3 extensions:
    X509v3 Basic Constraints:
    CA:FALSE
    Netscape Cert Type:
    SSL Client, S/MIME
    Netscape Comment:
    OpenSSL Generated Client Certificate
    X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
    X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

    X509v3 Key Usage: critical
    Digital Signature, Non Repudiation, Key Encipherment
    X509v3 Extended Key Usage:
    TLS Web Client Authentication, E-mail Protection
    X509v3 Subject Alternative Name: critical
    IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
    Signature Algorithm: ED25519
 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
 dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
 ba:1a:b4:17:c0:bb:0f:da:be:02

Re: client certs with no subjectName only SAN

[Viktor Dukhovni]

> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
>  wrote:
> 
> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD 
> mark subjectAltName as non-critical"

This is wrong.  When the subject DN is empty, the subjectAltName should be
marked as critical.  IIRC some Java implementations reject the certificate
otherwise.

> I can believe that OpenSSL doesn't support empty subjectName's.  An empty 
> one, with no relative disintuished name components, is not the same as not 
> present.

OpenSSL supports empty (empty RDN sequence) subject DNs.
The "-subj /" option is one way to make that happen.

Empty is of course different from "absent", which is not
possible, since the subject DN is a required component of
an X.509 certificate.

-- 
Viktor.

Re: Acquire Entropy for embedded platform

[Robert Moskowitz]

On 8/16/19 5:44 AM, Dr Paul Dale wrote:
I investigated HAVEGE fairly deeply a couple of years ago.  I am 
completely in agreement with the basis of this source, however the 
sticking point was the “expansion” phase.  Essentially, every bit of 
entropy gathered is turned into (just under) thirty two bits of 
“entropy”.  This is logically and physically impossible.  As a source, 
it appears reasonable to the usual tests (i.e. dieharder), although 
TestU01  does pick up on it 
being less than ideal.


I would, however, recommend Stephan Müller's CPU Jitter 
.  The 
gathering is well researched and performed, no hidden tricks are 
present and the bits produces are equiprobable.


Thanks.  I will take a look at CPU Jitter.  Entropy can be an issue on 
some of my armv7 boards.  I run CentOS on them, so all I need to find 
are rpms for something to test it out...





Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia




On 16 Aug 2019, at 7:31 pm, Robert Moskowitz > wrote:




On 8/16/19 5:26 AM, Chitrang Srivastava wrote:

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where 
I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?



Check out: https://issihosts.com/haveged

I talk about it here: 
http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

On 8/16/19 7:58 AM, Salz, Rich wrote:

In the same paragraph, the sentence before the one you're quoting says "If the 
subject field contains an empty sequence, then the issuing CA MUST include a 
subjectAltName extension that is marked as critical."
 


I will run another test today and see if it is as easy as claimed to 
flag SAN critical.




It's not possible to have a missing subject name in a certificate, the 
field is not OPTIONAL.


I was wondering more the construction of the cert when 'no 
subjectName'.  You confirmed that the object is there. Probably length 
0.  I will have to look at that asnparse listing more critically.


   
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 than I ever knew :)




Why I ask, perhaps seemingly dumb questions, here.  Those that really 
know the stuff are still around.


I learned enough ASN1 to get by with x.509 and snmp and have forgotten 
much of what I learned ~20 years ago.  I do have an iana enterprise 
number that I used in some of my OID proposals in both way back then.


The failing read access really bites.

thanks both of you.

Re: client certs with no subjectName only SAN

[Salz, Rich via openssl-users]

>In the same paragraph, the sentence before the one you're quoting says "If 
> the subject field contains an empty sequence, then the issuing CA MUST 
> include a subjectAltName extension that is marked as critical."

>It's not possible to have a missing subject name in a certificate, the 
> field is not OPTIONAL.
  
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 
than I ever knew :)

Re: Acquire Entropy for embedded platform

[Salz, Rich via openssl-users]

  *   Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default 
entropy sources.
  *   I dread the effort that this would entail.

Open an issue and maybe someone with an older platform will work on doing it.

I don’t think the project has any need to support such things.  (Members of the 
project working for companies, perhaps)

Re: Acquire Entropy for embedded platform

[Jakob Bohm via openssl-users]

Not just dedicated black box rngs in verious chips (such as
multifunction I/O chips or the old Intel BIOS chip), but also
general hardware that happens to have plenty of inherent
randomness due to its design or implementation.

The simple easy to add RNG circuits include some completely
open discrete designs if that's desired.

On 16/08/2019 12:53, Dr Paul Dale wrote:
I agree.  Using internal hardware in the processor for entropy depends 
on everything.  Each processor needs to be independently quantified 
and not doing so becomes a risk assessment.


As for hardware sources, they are essentially black boxes and could 
contain anything.  It is extremely difficult, if not impossible, to 
tell if the hardware RNG is good or not.  This doesn’t mean that they 
should not be used, it just means that using them involves another 
risk assessment.




On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
mailto:openssl-users@openssl.org>> wrote:


[Top posting for consistency]

More than OS dependency, this depends on the exact hardware on the 
platform:

CPU, support chips, peripheral chips.   Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC 
clock.
 And if none do, there are simple RNG hardware designs that could be 
added
in a corner of the circuit, either on a plugin board or as part of a 
board

already customized to the application.


On 16/08/2019 11:33, Dr Paul Dale wrote:
Two bits of RTC is nowhere near enough entropy.  I could break two 
bits by hand in a few seconds — there are only four possibilities.


The best outcome is an hardware random number generator.  These are 
often not readily available.


Next would be waiting for enough entropy from interrupts, timers and 
the like.


You didn’t specify what operating system/kernel you are using so 
further advise is less than useful.



On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
 
> wrote:


Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls 
where I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?





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

Re: Acquire Entropy for embedded platform

[Dr Paul Dale]

I agree.  Using internal hardware in the processor for entropy depends on 
everything.  Each processor needs to be independently quantified and not doing 
so becomes a risk assessment.

As for hardware sources, they are essentially black boxes and could contain 
anything.  It is extremely difficult, if not impossible, to tell if the 
hardware RNG is good or not.  This doesn’t mean that they should not be used, 
it just means that using them involves another risk assessment.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
>  wrote:
> 
> [Top posting for consistency]
> 
> More than OS dependency, this depends on the exact hardware on the platform:
> CPU, support chips, peripheral chips.   Usually some of these can provide
> much more randomness than the highly predictable time of day/year RTC clock.
>  And if none do, there are simple RNG hardware designs that could be added
> in a corner of the circuit, either on a plugin board or as part of a board
> already customized to the application.
> 
> 
> On 16/08/2019 11:33, Dr Paul Dale wrote:
>> Two bits of RTC is nowhere near enough entropy.  I could break two bits by 
>> hand in a few seconds — there are only four possibilities.
>> 
>> The best outcome is an hardware random number generator.  These are often 
>> not readily available.
>> 
>> Next would be waiting for enough entropy from interrupts, timers and the 
>> like.
>> 
>> You didn’t specify what operating system/kernel you are using so further 
>> advise is less than useful.
>> 
>> 
>>> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
>>> mailto:chitrang.srivast...@gmail.com>> 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am working on an embedded platform and now ported openssl 1.1.1b
>>> TLS 1.2/1.3 is working fine.
>>> While analysing random number , Rand pool initialization calls where I am 
>>> returning like this ,
>>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
>>> {
>>> return rand_pool_entropy_available(pool);
>>> }
>>> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits of 
>>> RTC, would that give enough entropy or any other recommendation to have 
>>> enough entropy for embedded platforms?
>>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 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
> 

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

In the same paragraph, the sentence before the one you're quoting says "If the 
subject field contains an empty sequence, then the issuing CA MUST include a 
subjectAltName extension that is marked as critical."

It's not possible to have a missing subject name in a certificate, the field is 
not OPTIONAL.

Cordialement,
Erwann Abalea

Le 15/08/2019 22:13, « openssl-users au nom de Salz, Rich via openssl-users » 
 a écrit 
:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"

I can believe that OpenSSL doesn't support empty subjectName's.  An empty 
one, with no relative disintuished name components, is not the same as not 
present.

Re: Acquire Entropy for embedded platform

[Chitrang Srivastava]

from the git repo of cpu jitter i see few files only so may be easy to
compile  at least.
Yeah it can be added to openssl source with macro to enable it.

On Fri, Aug 16, 2019 at 4:05 PM Dr Paul Dale  wrote:

> Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
> entropy sources.
> I dread the effort that this would entail.
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava <
> chitrang.srivast...@gmail.com> wrote:
>
> Thanks Pauli,
>
> I did checked CPU Jitter and it looks promising. It has openssl engine
> support too.
> So i guess I have to add this add provide OS specific calls and it should
> work.
> Will keep you posted.
>
> Thanks,
>
>
> On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale  wrote:
>
>> I investigated HAVEGE fairly deeply a couple of years ago.  I am
>> completely in agreement with the basis of this source, however the sticking
>> point was the “expansion” phase.  Essentially, every bit of entropy
>> gathered is turned into (just under) thirty two bits of “entropy”.  This is
>> logically and physically impossible.  As a source, it appears reasonable to
>> the usual tests (i.e. dieharder), although TestU01
>>  does pick up on it being less
>> than ideal.
>>
>> I would, however, recommend Stephan Müller's CPU Jitter
>> .  The gathering
>> is well researched and performed, no hidden tricks are present and the bits
>> produces are equiprobable.
>>
>>
>> Pauli
>> --
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
>> Phone +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>>
>> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz  wrote:
>>
>>
>>
>> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>>
>> Hi,
>>
>> I am working on an embedded platform and now ported openssl 1.1.1b
>> TLS 1.2/1.3 is working fine.
>> While analysing random number , Rand pool initialization calls where I am
>> returning like this ,
>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
>> {
>> return rand_pool_entropy_available(pool);
>> }
>> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits
>> of RTC, would that give enough entropy or any other recommendation to have
>> enough entropy for embedded platforms?
>>
>>
>>
>> Check out:https://issihosts.com/haveged
>>
>> I talk about it here:
>> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS
>>
>>
>>
>>
>

Re: Acquire Entropy for embedded platform

[Jakob Bohm via openssl-users]

[Top posting for consistency]

More than OS dependency, this depends on the exact hardware on the platform:
CPU, support chips, peripheral chips.   Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC clock.
 And if none do, there are simple RNG hardware designs that could be added
in a corner of the circuit, either on a plugin board or as part of a board
already customized to the application.


On 16/08/2019 11:33, Dr Paul Dale wrote:
Two bits of RTC is nowhere near enough entropy.  I could break two 
bits by hand in a few seconds — there are only four possibilities.


The best outcome is an hardware random number generator.  These are 
often not readily available.


Next would be waiting for enough entropy from interrupts, timers and 
the like.


You didn’t specify what operating system/kernel you are using so 
further advise is less than useful.



On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
> wrote:


Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where 
I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?


Thanks,










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

Re: Acquire Entropy for embedded platform

[Chitrang Srivastava]

Thanks Pauli,

I did checked CPU Jitter and it looks promising. It has openssl engine
support too.
So i guess I have to add this add provide OS specific calls and it should
work.
Will keep you posted.

Thanks,


On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale  wrote:

> I investigated HAVEGE fairly deeply a couple of years ago.  I am
> completely in agreement with the basis of this source, however the sticking
> point was the “expansion” phase.  Essentially, every bit of entropy
> gathered is turned into (just under) thirty two bits of “entropy”.  This is
> logically and physically impossible.  As a source, it appears reasonable to
> the usual tests (i.e. dieharder), although TestU01
>  does pick up on it being less
> than ideal.
>
> I would, however, recommend Stephan Müller's CPU Jitter
> .  The gathering
> is well researched and performed, no hidden tricks are present and the bits
> produces are equiprobable.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz  wrote:
>
>
>
> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>
> Hi,
>
> I am working on an embedded platform and now ported openssl 1.1.1b
> TLS 1.2/1.3 is working fine.
> While analysing random number , Rand pool initialization calls where I am
> returning like this ,
> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
> {
> return rand_pool_entropy_available(pool);
> }
> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits
> of RTC, would that give enough entropy or any other recommendation to have
> enough entropy for embedded platforms?
>
>
>
> Check out:https://issihosts.com/haveged
>
> I talk about it here:
> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS
>
>
>
>

Re: Acquire Entropy for embedded platform

[Dr Paul Dale]

I investigated HAVEGE fairly deeply a couple of years ago.  I am completely in 
agreement with the basis of this source, however the sticking point was the 
“expansion” phase.  Essentially, every bit of entropy gathered is turned into 
(just under) thirty two bits of “entropy”.  This is logically and physically 
impossible.  As a source, it appears reasonable to the usual tests (i.e. 
dieharder), although TestU01  does pick 
up on it being less than ideal.

I would, however, recommend Stephan Müller's CPU Jitter 
.  The gathering is 
well researched and performed, no hidden tricks are present and the bits 
produces are equiprobable.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz  wrote:
> 
> 
> 
> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>> Hi,
>> 
>> I am working on an embedded platform and now ported openssl 1.1.1b
>> TLS 1.2/1.3 is working fine.
>> While analysing random number , Rand pool initialization calls where I am 
>> returning like this , 
>> size_t rand_pool_acquire_entropy(RAND_POOL *pool)
>> {
>> return rand_pool_entropy_available(pool);
>> }  
>> As noticed that rand_unix.c has an implementation wcih samples 2 bits of 
>> RTC, would that give enough entropy or any other recommendation to have 
>> enough entropy for embedded   platforms?
> 
> 
> Check out:https://issihosts.com/haveged 
> 
> I talk about it here:
> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS 
> 
> 
> 

Re: Acquire Entropy for embedded platform

[Dr Paul Dale]

Two bits of RTC is nowhere near enough entropy.  I could break two bits by hand 
in a few seconds — there are only four possibilities.

The best outcome is an hardware random number generator.  These are often not 
readily available.

Next would be waiting for enough entropy from interrupts, timers and the like.

You didn’t specify what operating system/kernel you are using so further advise 
is less than useful.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
>  wrote:
> 
> Hi,
> 
> I am working on an embedded platform and now ported openssl 1.1.1b
> TLS 1.2/1.3 is working fine.
> While analysing random number , Rand pool initialization calls where I am 
> returning like this , 
> size_t rand_pool_acquire_entropy(RAND_POOL *pool)
> {
> return rand_pool_entropy_available(pool);
> }  
> As noticed that rand_unix.c has an implementation wcih samples 2 bits of RTC, 
> would that give enough entropy or any other recommendation to have enough 
> entropy for embedded platforms?
> 
> Thanks,
> 
> 
> 
> 
> 

Re: Acquire Entropy for embedded platform

[Robert Moskowitz]

On 8/16/19 5:26 AM, Chitrang Srivastava wrote:

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I 
am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?



Check out:    https://issihosts.com/haveged

I talk about it here: 
http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS

Acquire Entropy for embedded platform

[Chitrang Srivastava]

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I am
returning like this ,
size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 bits of
RTC, would that give enough entropy or any other recommendation to have
enough entropy for embedded platforms?

Thanks,