[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pf_key comments (random number generation)
John,
If one has a good hardware RNG, nothing you do with the output in
software is likely to improve on the output, and many things that you do
could degrade the result. I acknowledge that if you lack confidence in the
hardware RNG output, then you have a problem, and then it might be
appropriate to try to improve on the output with good software (although
use of a second hardware RNG would be better). However, we have many more
examples of bad software PRNGs than bad hardware RNGs.
I also am very skeptical that application-based PRNG sources are an
improvement over good, kernel PRNG sources; I suspect the opposite is true
in most cases. I'd rather not see an API based on the assumption that the
kernel code can't get it right and the application code will do better.
Should we ever evolve to more secure OSs, the likelihood is much greater
that Trojan Horse software will be able to degrade the application
environment PRNG than a kernel-based PRNG. Also, we are ultimately
dependent on the security of kernel code anyway, to protect user traffic
from disclosure. So, I tend to think that suggestion of making specific API
provisions for application-supplied PRNG data is questionable.
In a more general vein, while I too do not profess to have examined
the pf_key interface in detail, I am puzzled by several of the suggestions
I have seen in this thread.
- Making a kernel call to get an IV (or a sequence of IVs), which
the application would pass back with a packet to be protected, seems very
odd to me. IV generation si a side effect of IPSEC (ESP) use, and is
dependent on the algorithm and the mode being employed. So, it seems
appropriate to let the IPSEC implementation handle the IV generation and
use, to hide the details from applications.
- The discussions about user vs. kernel performance for the IV
generation task also struck me as odd. In general, I don't think we want to
make user code knowledgable about the crypto details of IPSEC, so IV
management really should be hidden in the IPSEC code, not visible to the
caller.
- As others have pointed out, after an initial IV has been
generated for a CBC session, one can just use the last ciphertext block
from packet N as the IV for packet N+1, just as one dies within the context
of a single packet. The specs for use of DES in this mode do allow re-use
of the first IV for subsequent packets, but that always struck me as a
bandwidth-saving measure that was not worth the potential security
downside. However, the same spec points to the need to protect the first
IV against modification attacks, e.g., by encrypting it using ECB mode, on
the assumption that a constant IV is used for every packet. The reasons for
this are left as an exercise for the reader, and for explication by the
list members who do not shrink from being called cryptographers!
Steve
References: