WARNING pseudorandom rekeying

[Emmanuel Dreyfus]

I have that messages on an i386 6.1.2 Xen machine:
cprng cpu0-short: WARNING pseudorandom rekeying.
cprng 47814d1: WARNING pseudorandom rekeying.
cprng sysctl: WARNING pseudorandom rekeying.

What does it means? I just upgraded the kernel to 6.1.2 to regenerate
weak RSA keys generated on 6.0. The warning suggests pseudorandom
generator could be kinked. Is it safe to generate keys?

[Jean-Yves Migeon]

Post by Emmanuel Dreyfus
cprng cpu0-short: WARNING pseudorandom rekeying.
cprng 47814d1: WARNING pseudorandom rekeying.
cprng sysctl: WARNING pseudorandom rekeying.
What does it means? I just upgraded the kernel to 6.1.2 to regenerate
weak RSA keys generated on 6.0. The warning suggests pseudorandom
generator could be kinked. Is it safe to generate keys?

I suppose you get these messages at boot from a domU.

It means that the RNG was seeded with a (supposedly) bad state, e.g.
with not enough random bits to be deemed safe.

It is generally not safe to keep long term keys generated during that
state. The output of "rndctl -s" can show whether the situation is
tolerable and evolving (generally when the rc script load the
random_seed file).

IMHO long term keys should not be created directly from a domU, let
alone a VM; running a "dd if=/dev/random count=16 bs=1" can almost hang
indefinetly in a domU, or (even worse) output not-so-random bits with
other kind of VM subsystems (KVM without virtio-rng drivers). On a
generic host it should return almost instantly.

[Emmanuel Dreyfus]

Post by Jean-Yves Migeon
It means that the RNG was seeded with a (supposedly) bad state, e.g.
with not enough random bits to be deemed safe.
It is generally not safe to keep long term keys generated during
that state.

IMO there is something to fix, as it is easy to miss the message
during first boot.

Post by Jean-Yves Migeon
IMHO long term keys should not be created directly from a domU, let
alone a VM; running a "dd if=/dev/random count=16 bs=1" can almost
hang indefinetly in a domU, or (even worse) output not-so-random
bits with other kind of VM subsystems (KVM without virtio-rng
drivers). On a generic host it should return almost instantly.

If I understand correctly, the only problem for keys generated in
a NetBSD domU is performances? If there is not enough randomness,
it will just wait?

[Jean-Yves Migeon]

Post by Emmanuel Dreyfus

Post by Jean-Yves Migeon
It means that the RNG was seeded with a (supposedly) bad state, e.g.
with not enough random bits to be deemed safe.
It is generally not safe to keep long term keys generated during
that state.

IMO there is something to fix, as it is easy to miss the message
during first boot.

The fix ain't that easy; how do you expect an environment to provide
sufficient entropy when:
- all devices and interrupts are virtualized therefore considerably
reducing timestamp quality regarding entropy;
- there is no trusted hardware entropy source queriable early during
boot (rdrand OP is only found on recent Intel CPU, and some people do
not consider it trustworthy).

For an interesting read, see
http://mail-index.netbsd.org/port-xen/2012/02/24/msg007173.html

I do not know whether sysinst could install a random_seed file right
before restart; that would allow a first, fresh boot to begin with a
(not so bad) entropy state.

domU situation adds another layer of limitation too: most of the time it
does not start with /boot (except when using pygrub thingies), the
kernel is directly loaded by dom0. So it cannot rely on rndseed from
boot.cfg.

Post by Emmanuel Dreyfus

Post by Jean-Yves Migeon
IMHO long term keys should not be created directly from a domU, let
alone a VM; running a "dd if=/dev/random count=16 bs=1" can almost
hang indefinetly in a domU, or (even worse) output not-so-random
bits with other kind of VM subsystems (KVM without virtio-rng
drivers). On a generic host it should return almost instantly.

If I understand correctly, the only problem for keys generated in
a NetBSD domU is performances?

No; entropy quality. Unless someone changed it recently, Manuel never
considered frontend drivers as a good source of entropy. Other domUs can
correlate their virtual interrupts and "guess" the timestamps for
another VM. Side channels may also leak information on calculus, but
that should not be your problem as you are not hosting hostile VMs, do
you :) ?

Post by Emmanuel Dreyfus
If there is not enough randomness,
it will just wait?

I would ask tls@ about current's cprng(9) behavior. IMHO that depends on
the device you use to get entropy from: /dev/random may block for a very
long time; while /dev/urandom will give you enough bytes back but with a
weakly-seeded PRNG.

I never seen a standardized API for Xen domU to query randomness from
dom0 (anyone is invited to prove me wrong). Perhaps virtio-rng from KVM
is a possibility, but I do not know its architecture. It might not be
suitable.

[John Nemeth]

On Dec 29, 4:02pm, Jean-Yves Migeon wrote:
} Le 29/12/2013 05:43, Emmanuel Dreyfus a écrit :
} > On Sun, Dec 29, 2013 at 03:05:12AM +0100, Jean-Yves Migeon wrote:
} >> It means that the RNG was seeded with a (supposedly) bad state, e.g.
} >> with not enough random bits to be deemed safe.
} >>
} >> It is generally not safe to keep long term keys generated during
} >> that state.
} >
} > IMO there is something to fix, as it is easy to miss the message
} > during first boot.
}
} The fix ain't that easy; how do you expect an environment to provide
} sufficient entropy when:
} - all devices and interrupts are virtualized therefore considerably
} reducing timestamp quality regarding entropy;
} - there is no trusted hardware entropy source queriable early during
} boot (rdrand OP is only found on recent Intel CPU, and some people do
} not consider it trustworthy).
}
} For an interesting read, see
} http://mail-index.netbsd.org/port-xen/2012/02/24/msg007173.html
}
} I do not know whether sysinst could install a random_seed file right
} before restart; that would allow a first, fresh boot to begin with a
} (not so bad) entropy state.
}
} domU situation adds another layer of limitation too: most of the time it
} does not start with /boot (except when using pygrub thingies), the
} kernel is directly loaded by dom0. So it cannot rely on rndseed from
} boot.cfg.

pygrub just extracts the kernel (and ramdisk for linux) from
the domU, places it in a temporary file, and passes the path to
the domU creator. The process after that is exactly as it would
be if pygrub wasn't being used. In otherwords, /boot still wouldn't
be used.

}-- End of excerpt from Jean-Yves Migeon

[Jean-Yves Migeon]

Le 29/12/2013 20:59, John Nemeth a écrit :
[snip]

Post by John Nemeth
pygrub just extracts the kernel (and ramdisk for linux) from
the domU, places it in a temporary file, and passes the path to
the domU creator. The process after that is exactly as it would
be if pygrub wasn't being used. In otherwords, /boot still wouldn't
be used.

Ach, that is true. I meant its successor (pvgrub) which runs a
paravirtualized grub in domU context.

However the comment still holds, I don't think it would be able to
chainload /boot successfully.

[Emmanuel Dreyfus]

Post by Jean-Yves Migeon

Post by Emmanuel Dreyfus
cprng cpu0-short: WARNING pseudorandom rekeying.
cprng 47814d1: WARNING pseudorandom rekeying.
cprng sysctl: WARNING pseudorandom rekeying.

(...)

Post by Jean-Yves Migeon
It means that the RNG was seeded with a (supposedly) bad state, e.g.
with not enough random bits to be deemed safe.

The nasty thing here is that if one did not check the boot log when
the key was created, there is no reminder.

Is there a way to assess existing private key quality?

--
Emmanuel Dreyfus
***@netbsd.org

[Jean-Yves Migeon]

Post by Emmanuel Dreyfus

Post by Jean-Yves Migeon

Post by Emmanuel Dreyfus
cprng cpu0-short: WARNING pseudorandom rekeying.
cprng 47814d1: WARNING pseudorandom rekeying.
cprng sysctl: WARNING pseudorandom rekeying.

(...)

Post by Jean-Yves Migeon
It means that the RNG was seeded with a (supposedly) bad state, e.g.
with not enough random bits to be deemed safe.

The nasty thing here is that if one did not check the boot log when
the key was created, there is no reminder.
Is there a way to assess existing private key quality?

I don't think it is possible; key parameters do not keep information
about the state they were created in. The system is weak not because the
key is invalid but rather because an attacker has fewer states to test
before being successful.

[Emmanuel Dreyfus]

Post by Jean-Yves Migeon
I don't think it is possible; key parameters do not keep information
about the state they were created in. The system is weak not because
the key is invalid but rather because an attacker has fewer states
to test before being successful.

But that assumes the attacker knows how the random generator was skewed,
dosn't it? And if the attacker can test it remotely, we should be able to
test it locally with access to the private key, or am I missing something?

[Jean-Yves Migeon]

Post by Emmanuel Dreyfus

Post by Jean-Yves Migeon
I don't think it is possible; key parameters do not keep information
about the state they were created in. The system is weak not because
the key is invalid but rather because an attacker has fewer states
to test before being successful.

But that assumes the attacker knows how the random generator was skewed,
dosn't it?

Yes. The attacker "guesses" the values by knowing that the OS is in its
early boot stage, with almost empty entropy pools and without external
events used to fill them up. The range of accessible values is limited,
so start with those first.

This of course requires good knowledge of the OS and its PRNG and the
way it boots.

Post by Emmanuel Dreyfus
And if the attacker can test it remotely, we should be able to
test it locally with access to the private key, or am I missing something?

I do not understand that part -- what do you mean? Collecting entropy
information through side channels like TCP ack/seq numbers, SYN cookies,
... ?

[Emmanuel Dreyfus]

Post by Jean-Yves Migeon

Post by Emmanuel Dreyfus
And if the attacker can test it remotely, we should be able to
test it locally with access to the private key, or am I missing something?

I do not understand that part -- what do you mean? Collecting entropy
information through side channels like TCP ack/seq numbers, SYN cookies,
... ?

If the attacker is able to factor a key using knowledge of skewed PRNG,
then we should be able to do the same in order to test key strength. And
since such a test would ran locally, it could have unlimited access to
crypto generated using the private key.

[j***@freeshell.org]

Not really following the current trajectory of this thread, however...

I found that updating the secondary boot-loader (i386) got rid of the

"cprng kernel: WARNING pseudorandom rekeying."

at boot-up. Not sure where I tracked the info down but I did make a
note to myself:

"Turns out the new kernel tries to pull in entropy from the disk and
if the secondary boot loader hasn't been updated that entropy isn't
available and the entropy pool gets drawn down quickly, which then
reverts to the pseudorandom device needing to generate some. Or
something to that effect. Copying /usr/mdec/boot to / is fix."

Anyway... maybe helpful for others coming across this after an upgrade.

--JW

[Jean-Yves Migeon]

Post by j***@freeshell.org
"Turns out the new kernel tries to pull in entropy from the disk and
if the secondary boot loader hasn't been updated that entropy isn't
available and the entropy pool gets drawn down quickly, which then
reverts to the pseudorandom device needing to generate some. Or
something to that effect. Copying /usr/mdec/boot to / is fix."
Anyway... maybe helpful for others coming across this after an upgrade.

Yes it is. Thanks for the heads up, bootloader's update is often
overlooked during upgrade.

People are accustomed to "copy kernel, reboot, tar base.tgz" or similar,
which is wrong IMHO (misses etcupdate, postinstall...)

[Fredrik Pettai]

Post by j***@freeshell.org
"Turns out the new kernel tries to pull in entropy from the disk and
if the secondary boot loader hasn't been updated that entropy isn't
available and the entropy pool gets drawn down quickly, which then
reverts to the pseudorandom device needing to generate some. Or
something to that effect. Copying /usr/mdec/boot to / is fix."
Anyway... maybe helpful for others coming across this after an upgrade.

Yes it is. Thanks for the heads up, bootloader's update is often overlooked during upgrade.
People are accustomed to "copy kernel, reboot, tar base.tgz" or similar, which is wrong IMHO (misses etcupdate, postinstall...)

But etcupdate, postinstall doesn't help you with updating the bootloader?
AFAIK, only sysinst does this if you do an upgrade…

/P

[Fredrik Pettai]

Post by Fredrik Pettai

Post by j***@freeshell.org
"Turns out the new kernel tries to pull in entropy from the disk and
if the secondary boot loader hasn't been updated that entropy isn't
available and the entropy pool gets drawn down quickly, which then
reverts to the pseudorandom device needing to generate some. Or
something to that effect. Copying /usr/mdec/boot to / is fix."
Anyway... maybe helpful for others coming across this after an upgrade.

Yes it is. Thanks for the heads up, bootloader's update is often overlooked during upgrade.
People are accustomed to "copy kernel, reboot, tar base.tgz" or similar, which is wrong IMHO (misses etcupdate, postinstall...)

But etcupdate, postinstall doesn't help you with updating the bootloader?
AFAIK, only sysinst does this if you do an upgrade…

Speaking of good procedures of updating the base system, isn't it time to import "sysupdate" (pkgsrc/sysutils/sysupdate) into the NetBSD now?

sysupdate makes it much easier to do system updates, and even supports doing unattended updates.

/P

[Fredrik Pettai]

blah… doing multiple thing at the same time sometimes causes confusion…

s/sysupdate/sysupgrade/g

http://www.netbsd.org/docs/guide/en/chap-upgrading.html#idm77006000

/P

[Brett Lymn]

Post by Fredrik Pettai
Speaking of good procedures of updating the base system, isn't it time to import "sysupdate" (pkgsrc/sysutils/sysupdate) into the NetBSD now?

Yes. sysupdate - Julian Fagir actually did some good work for the last
Google Summer of Code. We should be importing this.

[rudolf]

Post by Brett Lymn

Post by Fredrik Pettai
Speaking of good procedures of updating the base system, isn't it time to import "sysupdate" (pkgsrc/sysutils/sysupdate) into the NetBSD now?

Yes. sysupdate - Julian Fagir actually did some good work for the last
Google Summer of Code. We should be importing this.

What's wrong with pkgsrc? Why needs the sysutils/sysupgrade package to
be in base? Do you see any risks of sysupgrade becoming stale if it's
not developed inside the base? Or is your proposal based on an estimate
that e.g. "more than 90% of NetBSD users use sysutils/sysupgrade" or
"nearly all NetBSD users who don't use pkgsrc want to use
sysutils/sysupgrade"?

Just plain curious,

r.

[Benny Siegert]

What's wrong with pkgsrc? Why needs the sysutils/sysupgrade package to be in base?

Note that these are two different codebases: sysupdate, as developed by Julian Fagir is not the same thing as the sysupdate in pkgsrc. IIUC the former is considered the replacement of the latter.

--Benny.

[Fredrik Pettai]

Post by Benny Siegert

What's wrong with pkgsrc? Why needs the sysutils/sysupgrade package to be in base?

Note that these are two different codebases: sysupdate, as developed by Julian Fagir is not the same thing as the sysupdate in pkgsrc. IIUC the former is considered the replacement of the latter.

Right, It's easy to confuse them.

I was originally referring to pkgsrc/sysutils/sysupgrade which jmmv@ made over a year ago...
http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade

And now I learned about Julian Fagir's sysupdate GSoC (not present in pkgsrc).
http://mail-index.netbsd.org/tech-userlevel/2013/10/02/msg007956.html

I don't have any opinion regarding the two tools, but I do think that NetBSD has been lacking this type of tool to simplify upgrades/updates so any NetBSD user (especially the newcomers) can do it with a simple "one-liner".
So as long as any of sysupgrade/sysupdate gets included in NetBSD's distribution (before next major release of NetBSD is released), I'm happy with that. And kudos to both jmmv@ and jdf@ for their work on making NetBSD upgrades/updates much simpler.

Re,
/P

PS.
There are also older sysupdate scripts made by others. I think Hubertf's old blog post has most of them linked: http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20100104_0228.html
DS.

[Greg Troxel]

Post by Fredrik Pettai
Right, It's easy to confuse them.
http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade
And now I learned about Julian Fagir's sysupdate GSoC (not present in pkgsrc).
http://mail-index.netbsd.org/tech-userlevel/2013/10/02/msg007956.html

There is a third tool, which is etcmanage, and the associated
INSTALL-NetBSD script, which together have similar goals. etcmanage is
in pkgsrc/sysutils/etcmanage.

[Fredrik Pettai]

Post by Brett Lymn

Speaking of good procedures of updating the base system, isn't it time to import "sysupgrade" (pkgsrc/sysutils/sysupgrade) into the NetBSD now?

Yes. sysupdate - Julian Fagir actually did some good work for the last
Google Summer of Code. We should be importing this.

(I've been using jmmv's sysupgrade for some time now, and that works good. Updating NetBSD with it have becoming faster & simpler, saving time.)

I also tried to test sysupdate (http://www.google-melange.com/gsoc/project/google/gsoc2013/jdf/5822463824887808)
However, it's not possible to simply test it by pointing it at the regular NetBSD releases, as it requires extra data to be present on the ftp server (referring to the mtree/<RELEASE>/set.XXX checksum files).

- I guess a modification to "build.sh distribution" needs be added that also export the mtree dir + set files together with sets, to ease the distribution of the releases then they are made available on the ftp.

- I also noted that "sysbackup soft" isn't working according to the usage output you get from itself.
(however, "man sysbackup" indicates that there are more mandatory arguments needed...)

- sysrollback(8) is mentioned in sysbackup(8), but it's not bundled with the package (alias for sysbackup?)

- Tracking daily built releases (like netbsd-6) doesn't seem to work (although, that's not a major goal for this tool)

Are there any updates/fixes that to sysupdate & sysbackup somewhere? (the version I'm trying is 0.9)

What the next steps?

Re,
/P

[Julian Djamil Fagir]

Hi Fredrik,

Post by Fredrik Pettai

Post by Brett Lymn

Post by Fredrik Pettai
Speaking of good procedures of updating the base system, isn't it time
to import "sysupgrade" (pkgsrc/sysutils/sysupgrade) into the NetBSD now?

Yes. sysupdate - Julian Fagir actually did some good work for the last
Google Summer of Code. We should be importing this.

(I've been using jmmv's sysupgrade for some time now, and that works good.
Updating NetBSD with it have becoming faster & simpler, saving time.)
I also tried to test sysupdate
(http://www.google-melange.com/gsoc/project/google/gsoc2013/jdf/5822463824887808)
However, it's not possible to simply test it by pointing it at the regular
NetBSD releases, as it requires extra data to be present on the ftp server
(referring to the mtree/<RELEASE>/set.XXX checksum files).

when GSoC ended, I wrote a blog article about the project:

http://www.komkon2.de/dokuwiki/doku.php?id=blog:gsoc_is_over

I planned to publish it also on the NetBSD blog, but I don't remember why
this didn't happen.

The checksum and mtree files are the real problem: This would need a larger
integration in the NetBSD build infrastructure. I don't know how much work
this would actually be, so far there are two scripts that would have to be
run by me to update the mtree and checksum files.

Post by Fredrik Pettai
- I guess a modification to "build.sh distribution" needs be added that
also export the mtree dir + set files together with sets, to ease the
distribution of the releases then they are made available on the ftp.

No, build.sh will be fine. If you have the tarballs visible inside your
filesystem, sysupdate would not check for changed files.

Post by Fredrik Pettai
- I also noted that "sysbackup soft" isn't working according to the usage
output you get from itself. (however, "man sysbackup" indicates that there
are more mandatory arguments needed...)

The documentation needs to be updated. Benny started with this, but I didn't
push the changes yet. Anyway, the most recent version is in my repository.

Post by Fredrik Pettai
- sysrollback(8) is mentioned in sysbackup(8), but it's not bundled with
the package (alias for sysbackup?)
- Tracking daily built releases (like netbsd-6) doesn't seem to work
(although, that's not a major goal for this tool)
Are there any updates/fixes that to sysupdate & sysbackup somewhere? (the
version I'm trying is 0.9)
What the next steps?

There are some smaller issues, and Benny already started reviewing the code.
The reason I didn't continue pushing for it is simple: When I had the time, I
was waiting for reviews, and now I got the OK, but don't have time anymore.
If anybody else would like to import it, he should free to do so (but maybe
contact me beforehand), I personally won't have time for this before summer.

Regards, Julian

[Fredrik Pettai]

Hi Julian,

Post by Julian Djamil Fagir
Hi Fredrik,

Post by Fredrik Pettai

Post by Brett Lymn

Post by Fredrik Pettai
Speaking of good procedures of updating the base system, isn't it time
to import "sysupgrade" (pkgsrc/sysutils/sysupgrade) into the NetBSD now?

Yes. sysupdate - Julian Fagir actually did some good work for the last
Google Summer of Code. We should be importing this.

(I've been using jmmv's sysupgrade for some time now, and that works good.
Updating NetBSD with it have becoming faster & simpler, saving time.)
I also tried to test sysupdate
(http://www.google-melange.com/gsoc/project/google/gsoc2013/jdf/5822463824887808)
However, it's not possible to simply test it by pointing it at the regular
NetBSD releases, as it requires extra data to be present on the ftp server
(referring to the mtree/<RELEASE>/set.XXX checksum files).

http://www.komkon2.de/dokuwiki/doku.php?id=blog:gsoc_is_over
I planned to publish it also on the NetBSD blog, but I don't remember why
this didn't happen.
The checksum and mtree files are the real problem: This would need a larger
integration in the NetBSD build infrastructure. I don't know how much work
this would actually be, so far there are two scripts that would have to be
run by me to update the mtree and checksum files.

Ok.

Post by Julian Djamil Fagir

Post by Fredrik Pettai
- I guess a modification to "build.sh distribution" needs be added that
also export the mtree dir + set files together with sets, to ease the
distribution of the releases then they are made available on the ftp.

No, build.sh will be fine. If you have the tarballs visible inside your
filesystem, sysupdate would not check for changed files.

I don't follow?

Then I wrote ('modification to "build.sh distribution" …') I meant what you just wrote above, better integration in the NetBSD build infrastructure, so newly built distributions gets bundled with the stuff sysupdate needs to work.

Post by Julian Djamil Fagir

Post by Fredrik Pettai
- I also noted that "sysbackup soft" isn't working according to the usage
output you get from itself. (however, "man sysbackup" indicates that there
are more mandatory arguments needed...)

The documentation needs to be updated. Benny started with this, but I didn't
push the changes yet. Anyway, the most recent version is in my repository.

Ok, found it.

Post by Julian Djamil Fagir

Post by Fredrik Pettai
- sysrollback(8) is mentioned in sysbackup(8), but it's not bundled with
the package (alias for sysbackup?)
- Tracking daily built releases (like netbsd-6) doesn't seem to work
(although, that's not a major goal for this tool)
Are there any updates/fixes that to sysupdate & sysbackup somewhere? (the
version I'm trying is 0.9)
What the next steps?

There are some smaller issues, and Benny already started reviewing the code.

I'll start by testing the latest version, and see how that works…

Post by Julian Djamil Fagir
The reason I didn't continue pushing for it is simple: When I had the time, I
was waiting for reviews, and now I got the OK, but don't have time anymore.

(Too bad you didn't push out the blog article, then more people would probably know about it in time)

Post by Julian Djamil Fagir
If anybody else would like to import it, he should free to do so (but maybe
contact me beforehand), I personally won't have time for this before summer.

Thanks,
/P

[Benny Siegert]

Post by Fredrik Pettai

Post by Julian Djamil Fagir
The documentation needs to be updated. Benny started with this, but I didn't
push the changes yet. Anyway, the most recent version is in my repository.

Ok, found it.

Post by Julian Djamil Fagir
There are some smaller issues, and Benny already started reviewing the code.

I'll start by testing the latest version, and see how that works…

That would be me (bsiegert@). I submitted a bunch of improvements to
the manpage and made a few comments on the code itself. I have not
used sysupdate in anger though, it has been on my to-do list for a
while.

The problem is that my NetBSD box is now running the netbsd-amd64
continuous builder for Go, so I don't want to take it down for
maintenance ;).

--Benny.

[Jean-Yves Migeon]

Post by Emmanuel Dreyfus

Post by Jean-Yves Migeon

Post by Emmanuel Dreyfus
And if the attacker can test it remotely, we should be able to
test it locally with access to the private key, or am I missing something?

I do not understand that part -- what do you mean? Collecting entropy
information through side channels like TCP ack/seq numbers, SYN cookies,
... ?

If the attacker is able to factor a key using knowledge of skewed PRNG,
then we should be able to do the same in order to test key strength. And
since such a test would ran locally, it could have unlimited access to
crypto generated using the private key.

Disclaimer: not a cryptographer, so you should ask the ones out there
(Colin? :) ).

First things first: having access to the private key will give you all
you need anyway: P, Q (the primes), modulus (N), D (private exponent)
and E (public one, 65537 99% of the time). They are stored with the
private key:

$ openssl rsa -noout -text -in .ssh/id_rsa

The problem gets harder when you did not store P and Q (cipher/decipher
requires only N, D, and E). Getting back P and Q when N, D, E are known
seems non trivial to me (better ask a crypto for this).

A "skewed" PRNG matters when you originally select P and Q: you have to
get them at random, so someone has no way to know which ones are picked
up in a given range ( [2^511, 2^512] for example).
A skewed PRNG will not pick them "randomly". So your attacker will try
to generate primes knowing the weaknesses of your PRNG. That part is
important: you _have_ to know how the PRNG behaves in addition to its
state.

In your case the only way to test the "strength" of your key set is:
- to get P and Q back (easy: see above);
- have a test that verify they are not trivial given the knowledge you
have about the PRNG.

I am not aware of such a test for Lunix's PRNG, even less so for the
NetBSD/FreeBSD one.

[Fredrik Pettai]

While at the topic randomness, would be good if NetBSD could implement an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing & inserting from other random sources, like the YubiHSM etc.

/P

[Justin Cormack]

Post by Fredrik Pettai
While at the topic randomness, would be good if NetBSD could implement an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing & inserting from other random sources, like the YubiHSM etc.

It does, RNDADDDATA. However you might want to write a driver, as the
ioctl does not add to the entropy count (because userspace is
untrusted).

Justin

[Fredrik Pettai]

Post by Justin Cormack

Post by Fredrik Pettai
While at the topic randomness, would be good if NetBSD could implement an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing & inserting from other random sources, like the YubiHSM etc.

It does, RNDADDDATA. However you might want to write a driver, as the
ioctl does not add to the entropy count (because userspace is
untrusted).

Or perhaps a simpler idea would be to add a sysctl option that gives you a choice whether it should accept entropy from userspace or not?

/P

[Havard Eidnes]

Post by Fredrik Pettai

Post by Justin Cormack

Post by Fredrik Pettai
While at the topic randomness, would be good if NetBSD could
implement an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing &
inserting from other random sources, like the YubiHSM etc.

It does, RNDADDDATA. However you might want to write a driver, as the
ioctl does not add to the entropy count (because userspace is
untrusted).

Or perhaps a simpler idea would be to add a sysctl option that
gives you a choice whether it should accept entropy from
userspace or not?

If I'm not terribly mistaken, it is there already, and is called
kern.securelevel. :) The kernel adds an entropy estimation if

estimate_ok = !kauth_authorize_device(cred,
KAUTH_DEVICE_RND_ADDDATA_ESTIMATE, NULL, NULL, NULL, NULL);

I beleive this got turned into "is securelevel > 0", but forgot
how to go about finding the appropriate code in the kauth code.

But ... it's probably not a very good idea to lower securelevel
(if your system runs with non-default securelevel) just to get
"better" entropy.

Regards,

- Håvard

[Jean-Yves Migeon]

Post by Fredrik Pettai
While at the topic randomness, would be good if NetBSD could implement
an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing & inserting from
other random sources, like the YubiHSM etc.

RNDADDDATA ?

http://netbsd.gw.com/cgi-bin/man-cgi?rnd++NetBSD-current

[Fredrik Pettai]

Post by Jean-Yves Migeon

Post by Fredrik Pettai
While at the topic randomness, would be good if NetBSD could implement
an ioctl like Linux RNDADDENTROPY?
This helps to increase the randomness by importing & inserting from
other random sources, like the YubiHSM etc.

RNDADDDATA ?
http://netbsd.gw.com/cgi-bin/man-cgi?rnd++NetBSD-current

Sorry, I missed that it had been implemented already...