Bug 19756
Summary: | possible key generation problem | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <mal> |
Component: | openssh | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | ckjohnson, djm, dr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-02-02 16:07:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2000-10-25 15:27:58 UTC
My kernel picks up around 400 bytes of entropy during bootup prior to sshd starting, measured by adding: (sleep 5 ; killall dd) & dd if=/dev/random of=/tmp/rand bs=1 to /etc/rc.d/init.d/sshd's start case. Around 384 bytes are required in the worst case: generation of DSA host key (which does a DSA parameter generation implicitly) and generation of an RSA key. This is a little too close for comfort, but I think that you would have a hard time creating a real attack out of it. The problem could be mitigated somewhat if anaconda wrote a random seed to /var/run/random-seed after the installation. The installer would pick up a lot of entropy from all the disk and keyboard/mouse activity during install. It might also be worthwhile increasing the size of the kernel entropy pool for the 2.2 kernels (2.4 can do it through proc): 512 bytes just isn't enough, especially if you are doing SSL or IPsec. linux/drivers/char/random.c supports pools up to 8k.with a simple #define To ask user for key pressing on boot isn't a good idea. What about unattended machines? The real solution is to use true random HW generator in current chipsets but this has nothing to do with openssh which simply uses what the kernel provides. So feel free to report enhancement requests against kernel. |