[Pkg-openssl-devel] Fwd: RDRAND for openssl should be disabled by default but it isnt

[Sebastian Andrzej Siewior]

On 2022-09-17 22:28:56 [+0200], report.problemissue at secure.mailbox.org wrote:
> openssl on bullseye and bookworm/sid/testing is affected
…
> (rdrand) Intel RDRAND engine
>  [RAND]
…
> https://wiki.openssl.org/index.php/Library_Initialization#ENGINEs_and_RDRAND
…
> 
> "A call to ENGINE_load_builtin_engines loads all built-in engines, including
> those for AES_NI instructions and RDRAND. After the call, OpenSSL will use
> the engines for AES encryption and random number generation, if available.
> In this case, RDRAND will be the only source of random numbers. ". shows it
> uses RDRAND as one and only source of random numbers. Not a good idea.

I can't ack this. Maybe Kurt can correct me. Based on my understanding
ENGINE_load_builtin_engines() loads the internal RDRAND-engine but one
still needs to:
|	eng = ENGINE_by_id("rdrand");
|	ENGINE_init(eng);
|	ENGINE_set_default(eng,  ENGINE_METHOD_RAND);

to get RAND_bytes() to use it. Otherwise it is loaded but not active and
keeps using getrandom().
…

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732710
> debian/patches/no_default_rdrand.patch is not applied anymore.

I can't find that one at all. What we had at the time was
	https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff_plain;h=8f68678989a198ead3ab59a698302ecb0f1c8fb1

cherry-picked for 1.0.1e-5 as a closer for #732710. That patch was
probably only in Ubuntu (if at all). So we didn't drop that.

…
> https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J show Intel
> applied pressure to let /dev/random rely on RDRAND instruction only. Intel
> is a strategic partner of ... who wants to weaken encryption for national
> security reasons, putting all users and organizations in jeopardy.

I'm not going to comment on that one. But this one of the reasons why
taking the whole email seriously and not stamp it as trolling is not
easy as it looks… But I do try here.

…
> DSA number is desired!

so on the technical side:
- on Linux the getrandom() syscall is used to seed the internal cprng
  state and provide random numbers. 

- I prefer it that way because getrandom() is created out of several
  entropy sources and does not rely on one like the rdrand/rdseed
  opcode. Which means even if rdrand is busted it does not break the
  whole system/ syscall.

- On some AMD boxes rdrand was broken and I don't remember if it was
  fixed via BIOS update or not. I also don't remember if it always
  returned 0x0 with or without error but I know that there is a
  workaround in kernel to disable on resume on certain machines:
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c49a0a80137c7ca7d6ced4c812c9e07a949f6f24

  because it did not behave properly so it should be "safe" now.

- However I would prefer to not use it at all and rely on the syscall
  for the reasons mentioned (multiple entropy sources). Therefore on the
  next upload, I would disable the rdrand engine. I would also do that
  for stable once I get around it.

- I don't see the need to issue a DSA and/ or deal with this asap since
  based on my check one needs to explictly enable that engine. I tried
  check codesearch.d.n if this is done within the archive but failed to
  do so.
  I may stand correcred :)

Sebastian