On Wed, Dec 17, 2008 at 03:02:54PM -0500, Perry E. Metzger wrote:
> The longer I'm in this field, the more the phrase "use with extreme
> caution" seems to mean "don't use" to me. More and more, I think that
> if you don't have a really good way to test and get assurance about a
> component of your
Charles Jackson wrote:
>
> I probably should not be commenting, not being a real device guy. But,
> variations in temperature and time could be expected to change SSD timing.
> Temperature changes will probably change the power supply voltages and shift
> some of the thresholds in the devices.
On Wed, 17 Dec 2008 13:02:58 -0500
Jerry Leichter wrote:
> On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote:
> > I probably should not be commenting, not being a real device guy.
> > But,
> > variations in temperature and time could be expected to change SSD
> > timing.
> > Temperature cha
Jerry Leichter writes:
> SSD's are complicated devices.
Complexity makes it hard to understand the security characteristics of
relying on the timing of the devices.
> So ... use with extreme caution. Estimate conservatively. Mix any
> apparent entropy you get with other sources.
The longer I
On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote:
I probably should not be commenting, not being a real device guy.
But,
variations in temperature and time could be expected to change SSD
timing.
Temperature changes will probably change the power supply voltages
and shift
some of the thre
=?ISO-8859-1?Q?Joachim_Str=F6mbergson?= writes:
>Damien Miller wrote:
>> Until someone runs your software on a SSD instead of a HDD. Oops.
>
>That is a very good observation. I would bet loads of GM stocks that very few
>people realise that moving from 0ld sk00l HDD to SSD would affect their
>entr
Bill Frantz writes:
>I find myself in this situation with a design I'm working on. I have an ARM
>chip, where each chip has two unique numbers burned into the chip for a total
>of 160 bits. I don't think I can really depend on these numbers being secret,
>since the chip designers thought they wou
On Tue, 16 Dec 2008, mhey...@gmail.com wrote:
> On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller wrote:
> > On Thu, 11 Dec 2008, James A. Donald wrote:
> >
> >> If one uses a higher resolution counter - sub
> >> microsecond - and times multiple disk accesses, one gets
> >> true physical randomness,
On Dec 15, 2008, at 2:28 PM, Joachim Strömbergson wrote:
...One could probably do a similar comparison to the increasingly
popular
idea of building virtual LANs to connect your virtualized server
running
on the same physical host. Ethernet frame reception time variance as
well as other real p
On Dec 16, 2008, at 12:10 PM, Simon Josefsson wrote:
...I agree with your recommendation to write an AES key to devices at
manufacturing time. However it always comes with costs, including:
1) The cost of improving the manufacture process sufficiently well to
make it unlikely that compromised A
-Michael Heyman
Wrote:
Before we give up on using drive timings [as an entropy source], does anyone
have evidence to
verify this assertion [that SSD drives will have much less variation in
read/write timing]? The reviews I have seen using tools like HD
Tune and HD Tach seem to show timing noise r
"Perry E. Metzger" writes:
> This does necessitate an extra manufacturing step in which the device
> gets "individualized", but you're setting the default password to a
> per-device string and having that taped to the top of the box anyway,
> right? If you're not, most of the boxes will be vulner
On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller wrote:
> On Thu, 11 Dec 2008, James A. Donald wrote:
>
>> If one uses a higher resolution counter - sub
>> microsecond - and times multiple disk accesses, one gets
>> true physical randomness, since disk access times are
>> effected by turbulence, whi
Perry E. Metzger wrote:
[Snip admirably straightforward threat and requirements analysis]
Yes, you can attempt to gather randomness at run time, but there are
endless ways to screw that up -- can you *really* tell if your random
numbers are "random enough?" -- and in a cheap device with low
man
On Dec 15, 2008, at 2:09 PM, Perry E. Metzger wrote:
Bill Frantz writes:
I find myself in this situation with a design I'm working on. I
have an ARM chip, where each chip has two unique numbers burned
into the chip for a total of 160 bits. I don't think I can really
depend on these numbers bein
Bill Frantz wrote:
> Short of building special random number generation hardware, does
> anyone have any suggestions for additional sources?
Any unused input device with noise can be used. Examples:
Soundcard: http://www.av8n.com/turbid/
Camera: http://www.lavarnd.org/
If anything in the system
Damien Miller wrote:
On Thu, 11 Dec 2008, James A. Donald wrote:
If one uses a higher resolution counter - sub
microsecond - and times multiple disk accesses, one gets
true physical randomness, since disk access times are
effected by turbulence, which is physically true
random.
Until someone r
Aloha!
Damien Miller wrote:
> On Thu, 11 Dec 2008, James A. Donald wrote:
>
>> If one uses a higher resolution counter - sub
>> microsecond - and times multiple disk accesses, one gets
>> true physical randomness, since disk access times are
>> effected by turbulence, which is physically true
>>
Bill Frantz writes:
> I find myself in this situation with a design I'm working on. I
> have an ARM chip, where each chip has two unique numbers burned
> into the chip for a total of 160 bits. I don't think I can really
> depend on these numbers being secret, since the chip designers
> thought th
On Sun, 14 Dec 2008 15:40:10 -0800
Bill Frantz wrote:
> Short of building special random number generation hardware, does
> anyone have any suggestions for additional sources?
>
In my copious spare time, I've entertained thoughts of writing a FIPS
181 pronounceable password generator for the iPh
d...@mindrot.org (Damien Miller) on Friday, December 12, 2008 wrote:
>On Thu, 11 Dec 2008, James A. Donald wrote:
>
>> If one uses a higher resolution counter - sub
>> microsecond - and times multiple disk accesses, one gets
>> true physical randomness, since disk access times are
>> effected by t
On Thu, 11 Dec 2008, James A. Donald wrote:
> If one uses a higher resolution counter - sub
> microsecond - and times multiple disk accesses, one gets
> true physical randomness, since disk access times are
> effected by turbulence, which is physically true
> random.
Until someone runs your softw
Jack Lloyd wrote:
> I think the situation is even worse outside of the
> major projects (the OS kernels crypto implementations
> and the main crypto libraries). I think outside of
> those, nobody is even really looking. For instance -
>
> This afternoon I took a look at a C++ library called
> JUCE
On Fri, Nov 28, 2008 at 12:49:27PM -0500, Perry E. Metzger wrote:
>
> As it turns out, cryptographic pseudorandom number generators continue
> to be a good place to look for security vulnerabilities -- see the
> enclosed FreeBSD security advisory.
>
> The more things change, the more they stay th
On 1227894567 seconds since the Beginning of the UNIX epoch
"Perry E. Metzger" wrote:
>
>As it turns out, cryptographic pseudorandom number generators continue
>to be a good place to look for security vulnerabilities -- see the
>enclosed FreeBSD security advisory.
>
>The more things change, the mo
25 matches
Mail list logo
