On Thu, 12 September 2013 22:13:49 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 06:23:09PM -0400, Jörn Engel wrote:
> > It is worse in three ways:
> > - it costs performance,
> > - it may create a false sense of safety and
> > - it actively does harm if we credit it as entropy.
> >
> > Ho
On Thu, Sep 12, 2013 at 06:23:09PM -0400, Jörn Engel wrote:
> It is worse in three ways:
> - it costs performance,
> - it may create a false sense of safety and
> - it actively does harm if we credit it as entropy.
>
> How much weight you assign to each of those is up to you. So long as
> we don'
On Thu, 12 September 2013 16:51:15 -0700, Andy Lutomirski wrote:
>
> Supposedly, the Linux entropy pool has the property that mixing in
> even actively malicious data is no worse than not mixing in anything
> at all.
It is worse in three ways:
- it costs performance,
- it may create a false sense
On Thu, Sep 12, 2013 at 3:13 PM, Jörn Engel wrote:
> On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
>> On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
>> > On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>> >> But I also think that the existing (certified) TPMs are
On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
> On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
> > On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
> >> But I also think that the existing (certified) TPMs are good enough
> >> for direct use.
>
> > That is equivale
On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
> On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>> But I also think that the existing (certified) TPMs are good enough
>> for direct use.
> That is equivalent to trusting the TPM chip not to be malicious. It
Indeed. While it n
On Thu, Sep 12, 2013 at 2:57 PM, Jörn Engel wrote:
> On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>>
>> But I also think that the existing (certified) TPMs are good enough
>> for direct use.
>
> That is equivalent to trusting the TPM chip not to be malicious. It
> requires trust
On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>
> But I also think that the existing (certified) TPMs are good enough
> for direct use.
That is equivalent to trusting the TPM chip not to be malicious. It
requires trusting the chip designer, trusting every single employee of
the
>-Original Message-
>From: Andy Lutomirski [mailto:l...@amacapital.net]
>A TPM that has an excellent internal entropy source and is FIPS 140-2
>compliant with no bugs whatsoever may still use Dual_EC_DRBG, which looks
>increasingly likely to be actively malicious.
You can loo
On 09/11/2013 01:28 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 12:25:48PM -0700, H. Peter Anvin wrote:
>> This of course has been a long-running debate. Similarly, we could
>> make much better use of RDRAND if instead of doing data reduction in
>> rngd we could feed it to the pool and just
On Wed, Sep 11, 2013 at 12:25:48PM -0700, H. Peter Anvin wrote:
> This of course has been a long-running debate. Similarly, we could
> make much better use of RDRAND if instead of doing data reduction in
> rngd we could feed it to the pool and just credit fractional bits.
> The FIPS tests that rng
This of course has been a long-running debate. Similarly, we could make much
better use of RDRAND if instead of doing data reduction in rngd we could feed
it to the pool and just credit fractional bits. The FIPS tests that rngd runs
are weak and obsoleted, but perhaps better than nothing (now
On Wed, 2013-09-11 at 10:49 -0700, Andy Lutomirski wrote:
> On Wed, Sep 11, 2013 at 10:22 AM, David Safford wrote:
> >>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>
> A TPM that has an excellent internal entropy source and is FIPS 140-2
> compliant with no bugs whatsoever may still use Dual_EC_
On Wed, Sep 11, 2013 at 2:45 PM, Theodore Ts'o wrote:
> We should definitely do this. If the TPM driver could fetch some
> randomness and then call add_device_randomness() to feed this into the
> random driver's entropy pool when it initializes itself, that would be
> ***really*** cool.
rngd al
On Wed, Sep 11, 2013 at 12:06 PM, Jeff Garzik wrote:
> On Wed, Sep 11, 2013 at 2:45 PM, Theodore Ts'o wrote:
>> We should definitely do this. If the TPM driver could fetch some
>> randomness and then call add_device_randomness() to feed this into the
>> random driver's entropy pool when it initi
On Wed, Sep 11, 2013 at 10:49:59AM -0700, Andy Lutomirski wrote:
>
> A TPM that has an excellent internal entropy source and is FIPS 140-2
> compliant with no bugs whatsoever may still use Dual_EC_DRBG, which
> looks increasingly likely to be actively malicious.
To be fair, given the limited CPU
On Wed, Sep 11, 2013 at 10:22 AM, David Safford wrote:
>>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>>> It recently came to my attention that there are no standards whatsoever
>>> for random number generated by TPMs. In fact, there *are* TPMs where
>>> random numbers are generated by an encryp
>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>> It recently came to my attention that there are no standards whatsoever
>> for random number generated by TPMs. In fact, there *are* TPMs where
>> random numbers are generated by an encrypted nonvolatile counter (I do
>> not know which ones); this
On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
> It recently came to my attention that there are no standards whatsoever
> for random number generated by TPMs. In fact, there *are* TPMs where
> random numbers are generated by an encrypted nonvolatile counter (I do
> not know which ones); this is ap
It recently came to my attention that there are no standards whatsoever
for random number generated by TPMs. In fact, there *are* TPMs where
random numbers are generated by an encrypted nonvolatile counter (I do
not know which ones); this is apparently considered acceptable for the
uses of random
20 matches
Mail list logo
