1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
> Thanks for the suggestion - I had spotted it, but skipped over it temporarily since |
5 |
> there was no ebuild. |
6 |
> I also tried clrngd that someone suggested offlist - this doesn't seem to be generating |
7 |
> entropy fast enough and it takes over 60 seconds of 100% CPU to generate what it |
8 |
> does generate. |
9 |
|
10 |
timer_entropyd doesn't suffer from that particular problem. It will add |
11 |
a fair amount of randomness to your system and it will do it on a |
12 |
regular bases. It's not too hard on your CPU either. |
13 |
|
14 |
> I'm fairly sure that the answer here is to switch to using a lower quality rng for |
15 |
> the canary - this leaves the high quality rng for all important crypto related stuff |
16 |
> where we really shouldn't be compromising on quality. |
17 |
|
18 |
I'm not sure exactly how ssp is implemented in a nuts and bolts sort of |
19 |
way. However, I would say lowering the quality of the random data used |
20 |
for the canary would be a bad idea. It could allow someone to more |
21 |
easily compromise a system protected by ssp. A better aproach would be |
22 |
to find a way to add more high quality random data to the pool if that's |
23 |
what's causing the problem if at all possible. |
24 |
- -- |
25 |
Yes means no and no means yes. Delete all files [Y]? |
26 |
Joseph C. Lininger, <jbahm@××××××.net> |
27 |
-----BEGIN PGP SIGNATURE----- |
28 |
Version: GnuPG v1.4.9 (MingW32) |
29 |
|
30 |
iQEcBAEBCAAGBQJLlU0yAAoJEMh8jNraUiwqgLcH/0nWOTlsZLJcQ9r+i9El1B+7 |
31 |
HzmedRPmQ00aPkAZz6d9GldEH3ydxWxZMOvf7Wj4GVE3R99E6Ur/wT2lORx+YgBg |
32 |
tbi2wHh9pAXIJ/qhYuNtL4C38VwGimBLWuyHaUP4zQB0mNQ4nsC798s05FaPdwM7 |
33 |
TRbj8c15kQtWqUd2cpw4CnLJGMxotwj67YpofYmVStpnt3Nl9ppOCZXP3AFIADi9 |
34 |
r9kUW+rjBFFtYlt2eR077RheNtwqTAyx8fcAhWhzMaFSEgbd/r8b7RdVwMJMYo+/ |
35 |
ysD5XMkf+r7QftcNHWq3slxVBTbz/9dkDdrYjVEmfDhZtDgz1JOgkPcxeVvU6I4= |
36 |
=M6IN |
37 |
-----END PGP SIGNATURE----- |