Comments on http://www.openssl.org/~appro/OPENSSL_instrument_bus/ are
welcomed.
But here, I think you're measuring the difference between two clocks that
are derived from the same oscillator. That is worrisome. It seems
possible an adversary could analyze the device and describe the
Comments on http://www.openssl.org/~appro/OPENSSL_instrument_bus/ are
welcomed.
I did not analyse the architecture of tested processors to check
how many frequencies they are using and how they are generating
them, but isn't this just manifestation of the PLL characteristics?
Are you aware
I was trying to check certificate against CRL file. CRL is valid, link to
CRL Distribution Point is present in cert file and valid too. So I've
issued next command:
openssl verify -CAfile CA/cacert.pem -crl_check CA/newcerts/03.pem
and got:
CA/newcerts/03.pem:
error 3 at 0 depth lookup:unable
On 16.01.2012 10:30, Andy Polyakov wrote:
Are you aware of any quantitative PLL characteristics that can be
relevant in the context? Can *you* argue in favor of the hypothesis?
It's essential that somebody else but me argues to confirm or dismiss it.
Unfortunately I lack the math needed to do
On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote:
It seems you're trying to address more than just CVE-2011-1473 via
this patch, which results in a fairly large patch. Why do you need
to track client IP at all? This issue is about client's ability to
do unlimited number of
We've been using this general design on multi-user CPU's for a few years.
I'm happier with it there because even if the entropy source is just a
hardware PRNG there's enough other noise (bus stalls from other running
processes, interrupts etc) to ensure that it's going to be very very
difficult
