regenerate_ssh_host_keys doesn't generate Ed25519 key

[oittaa]

/etc/init.d/regenerate_ssh_host_keys doesn't generate Ed25519 key. This could be fixed by adding the following line:

      yes | ssh-keygen -q -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key && \

after

      yes | ssh-keygen -q -N '' -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key && \

[oittaa]

Another good idea might be to reseed /dev/urandom from hardware RNG to get more entropy for the key generation.

Adding this before the nohup line would implement it:

modprobe -q bcm2708-rng && dd if=/dev/hwrng of=/dev/urandom count=1 bs=4096 2>/dev/null

[oittaa]

Another good idea might be to reseed /dev/urandom from hardware RNG to get more entropy for the key generation.

Adding this before the nohup line would implement it:

modprobe -q bcm2708-rng && dd if=/dev/hwrng of=/dev/urandom count=1 bs=4096 2>/dev/null

[dev-tty]

Someone should really, really pay attention to this... This is a very, very big deal to device security!

[dev-tty]

Someone should really, really pay attention to this... This is a very, very big deal to device security!

[xcasex]

why is this report not handled? this is critical.

[xcasex]

why is this report not handled? this is critical.

[XECDesign]

It is. The key is generated in the new image. The entropy concern is not related to the original issue and needs to be reported separately with proof, not assertions. As I understand it, ssh-keygen will not generate any keys until it has enough entropy.

[XECDesign]

It is. The key is generated in the new image. The entropy concern is not related to the original issue and needs to be reported separately with proof, not assertions. As I understand it, ssh-keygen will not generate any keys until it has enough entropy.

[cryptax]

I don't think ssh-keygen will wait until it has enough entropy (if I am correct?) :
ssh-keygen is using /dev/urandom (see strace provided here), and /dev/urandom is a non-blocking random source.
So, the issue oittaa reports looks quite valid to me, and the suggestion to use bcm2708-rng nice too.
Sure, it would be better to have a proof of how much entropy is available at boot time, but it's not a reason not to patch/secure the code...

[cryptax]

I don't think ssh-keygen will wait until it has enough entropy (if I am correct?) :
ssh-keygen is using /dev/urandom (see strace provided here), and /dev/urandom is a non-blocking random source.
So, the issue oittaa reports looks quite valid to me, and the suggestion to use bcm2708-rng nice too.
Sure, it would be better to have a proof of how much entropy is available at boot time, but it's not a reason not to patch/secure the code...

[vladionescu]

The discussion here and on the RPi forums has been childish and, worse, dismissive of a contributor trying to solve a significant security problem.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=126892

Raspbian's reaction to this bug and contributor does not inspire confidence in the project.

Please reconsider patching the code.

[vladionescu]

The discussion here and on the RPi forums has been childish and, worse, dismissive of a contributor trying to solve a significant security problem.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=126892

Raspbian's reaction to this bug and contributor does not inspire confidence in the project.

Please reconsider patching the code.

[XECDesign]

To be clear, the entropy issue IS being looked at internally by multiple people and WILL be addressed. This particular issue wasn't closed because the entropy issue isn't important or is being ignored, but because it's not the original issue that was reported. And of course oittaa's contribution is appreciated.

[XECDesign]

To be clear, the entropy issue IS being looked at internally by multiple people and WILL be addressed. This particular issue wasn't closed because the entropy issue isn't important or is being ignored, but because it's not the original issue that was reported. And of course oittaa's contribution is appreciated.

[cryptax]

Oh right. Nice precision then, thanks. Is there a link to the issue is being addressed then?

[cryptax]

Oh right. Nice precision then, thanks. Is there a link to the issue is being addressed then?

[Harvester57]

Internally ? what does that even mean ? Too difficult to open a new bug report for us to comment ?

[Harvester57]

Internally ? what does that even mean ? Too difficult to open a new bug report for us to comment ?