On Wed, Jan 2, 2013 at 8:38 AM, Steve Litt wrote:
> On Mon, 31 Dec 2012 09:27:44 +0200
> Gilboa Davara wrote:
>
>> > It's a 180Gb Intel 520 Series SSD with firmware version 400i.
>> ...
>> > I have an ext4 filesystem on it.
>>
>> Semi-OT: A word of friendly warning:
>> I recently bricked a 120GB
On Tue, Jan 1, 2013 at 11:41 PM, E.S. Rosenberg
wrote:
>
> If it's encrypted with a good strength cypher and keylength then what
> are you worried about, they just have to return the encrypted blob to
> you?
I'm using luks for encryption with a fairly long key.
Never the less, for 500nis it
On Sun, Jan 6, 2013 at 1:34 AM, Amos Shapira wrote:
> If someone is really concerned about NSA knowing their random seed through
> Intel's hardware implementation - can't these few people add hardware RNG's
> to their sources?
> (one ref:
> http://en.wikipedia.org/wiki/Comparison_of_hardware_rand
gt; On 3 January 2013 11:42, Oleg Goldshmidt wrote:
>>
>>> On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El
>>> wrote:
>>> > On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re:
>>> SSD drives)":
>>> >> RDRAND
gt; wrote:
>> > On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD
>> drives)":
>> >> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way
>> >> faster than /dev/urandom (they state 500MiB per second), and you d
013 11:42, Oleg Goldshmidt wrote:
> On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El
> wrote:
> > On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD
> drives)":
> >> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way
> >> f
$ cat /dev/urandom >/dev/null
kernel panic: radiation higher than the maximal safe amount
On Thu, Jan 3, 2013 at 5:21 PM, Nadav Har'El wrote:
> On Thu, Jan 03, 2013, Michael Shiloh wrote about "Re: SSD drives":
> > perhaps they use radioactive decay? Scroll
I don't know if Intel uses this but as I recall it VIA claims to use
certain quantum effects as sources of entropy:
http://www.via.com.tw/en/initiatives/padlock/hardware.jsp
2013/1/3 Nadav Har'El :
> On Thu, Jan 03, 2013, Michael Shiloh wrote about "Re: SSD drives&quo
On 01/03/2013 07:21 AM, Nadav Har'El wrote:
On Thu, Jan 03, 2013, Michael Shiloh wrote about "Re: SSD drives":
perhaps they use radioactive decay? Scroll down to "Geiger Counter" at:
There's an inherent conflict between the number of bits of randomness you
ca
On Thu, Jan 03, 2013, Michael Shiloh wrote about "Re: SSD drives":
> perhaps they use radioactive decay? Scroll down to "Geiger Counter" at:
There's an inherent conflict between the number of bits of randomness you
can get out of this process, and the safety of the op
On 01/03/2013 05:25 AM, Oleg Goldshmidt wrote:
There is an additional
instruction, RDSEED, that is "supposedly" truly random, but, as I
mentioned, I have not seen an explanation of why it is or how it
works.
perhaps they use radioactive decay? Scroll down to "Geiger Counter" at:
http://www.
On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El wrote:
> On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD
> drives)":
>> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way
>> faster than /dev/urandom (they state 500MiB per se
On Thu, Jan 3, 2013 at 3:13 PM, Oleg Goldshmidt wrote:
>
> I'd say that it is up to Intel to prove that their TRNG design is
> truly non-deterministic.
Um, but in Intel's case, they at least *tried* to prove that their TRNG is
good enough. I don't think WD tries to make its seek times very rand
On Thu, Jan 3, 2013 at 1:45 PM, Nadav Har'El wrote:
> The whole point of the hardware random number generator is that it is
> *not* a PRNG, but rather some special hardware which supposedly uses
> sources of randomness (e.g., heat) not normally available for software.
"Supposedly" is the operati
On Thu, Jan 3, 2013 at 12:31 PM, Elazar Leibovich wrote:
> Instead of assuming, you should've used Google ;-)
Yes, but I am at work. ;-)
>
> To my (limited, I'm far from a crypto expert) understanding, Intel of course
> also seeds the PRNG with a true random number generator, and it complies
> N
On Thu, Jan 03, 2013, Elazar Leibovich wrote about "Re: RNG (was: Re: SSD
drives)":
> If you're a gateway that does SSL (and thus need to do many kex)? Like F5
This doesn't (I think) explain why you would need to do 100 million each
se
If you're a gateway that does SSL (and thus need to do many kex)? Like F5
On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El wrote:
> On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD
> drives)":
> > RDRAND is also a PRNG, reseeded at most once
On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD
drives)":
> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way
> faster than /dev/urandom (they state 500MiB per second), and you do not
> have its source code...
Can anyone give me an exam
On Thu, Jan 03, 2013, Oleg Goldshmidt wrote about "Re: SSD drives":
> 2) I would not only be worried about an NSA backdoor in Intel CPUs,
> but also about the degree of randomness of their generator. If it is
> flawed (and it is notoriously difficult to do a really good PRNG -
Instead of assuming, you should've used Google ;-)
To my (limited, I'm far from a crypto expert) understanding, Intel of
course also seeds the PRNG with a true random number generator, and it
complies NIST standard for randomness.
http://software.intel.com/en-us/blogs/2012/11/17/the-difference-be
On Thu, Jan 03, 2013 at 11:57:01AM +0200, Oleg Goldshmidt wrote:
> On Thu, Jan 3, 2013 at 10:53 AM, Baruch Siach wrote:
> > Hi Oleg,
> >
> > On Sun, Dec 30, 2012 at 10:40:31AM +0200, Oleg Goldshmidt wrote:
> >> On Sun, Dec 30, 2012 at 8:46 AM, shimi wrote:
> >> > I really don't think so. SSDs (IM
On Thu, Jan 3, 2013 at 10:53 AM, Baruch Siach wrote:
> Hi Oleg,
>
> On Sun, Dec 30, 2012 at 10:40:31AM +0200, Oleg Goldshmidt wrote:
>> On Sun, Dec 30, 2012 at 8:46 AM, shimi wrote:
>> > I really don't think so. SSDs (IMHO) makes computer much faster due to the
>> > VERY low seek time - the time
Hi Oleg,
On Sun, Dec 30, 2012 at 10:40:31AM +0200, Oleg Goldshmidt wrote:
> On Sun, Dec 30, 2012 at 8:46 AM, shimi wrote:
> > I really don't think so. SSDs (IMHO) makes computer much faster due to the
> > VERY low seek time - the time it takes you to get a block. Compare 10-20ms
> > with ~0.1ms.
On Mon, 31 Dec 2012 09:27:44 +0200
Gilboa Davara wrote:
> > It's a 180Gb Intel 520 Series SSD with firmware version 400i.
> ...
> > I have an ext4 filesystem on it.
>
> Semi-OT: A word of friendly warning:
> I recently bricked a 120GB Intel 520 w/ the latest firmware (not sure
> if it was 400i)
If it's encrypted with a good strength cypher and keylength then what
are you worried about, they just have to return the encrypted blob to
you?
2013/1/1 Gilboa Davara :
> On Mon, Dec 31, 2012 at 9:30 PM, Baruch Even wrote:
>> A good SSD must have enough capacitors/super-caps to protect itsel
On Mon, Dec 31, 2012 at 9:30 PM, Baruch Even wrote:
> A good SSD must have enough capacitors/super-caps to protect itself from
> such events, did you try to check with the vendor support?
As the SSD does contain sensitive (encrypted) information. I rather not RMA it.
Without it. there's not much
Whenever I see questions about SSD I am reminded of the following (a bit
dated but probably still relevant, unless someone can reference an update?):
http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html
-Amos
On Dec 31, 2012 5:28 AM, "Gilboa Davara" wrote:
> > It'
A good SSD must have enough capacitors/super-caps to protect itself from
such events, did you try to check with the vendor support?
On Mon, Dec 31, 2012 at 5:22 PM, Gilboa Davara wrote:
> On Mon, Dec 31, 2012 at 2:13 PM, Lior Okman wrote:
> >
> > On Mon, Dec 31, 2012 at 1:48 PM, Dan Shimshoni
On Mon, Dec 31, 2012 at 2:13 PM, Lior Okman wrote:
>
> On Mon, Dec 31, 2012 at 1:48 PM, Dan Shimshoni wrote:
>>
>> Hi,
>> >(Second bricked SSD in 12
>> >months)
>> >A *very* short power shortage crept under my APC UPS and >bricked the
>> > SSD.
>
>
> What type of UPS is this? Online or line-inter
On Mon, Dec 31, 2012 at 1:48 PM, Dan Shimshoni wrote:
> Hi,
> >(Second bricked SSD in 12
> >months)
> >A *very* short power shortage crept under my APC UPS and >bricked the SSD.
>
What type of UPS is this? Online or line-interactive? I'm guessing it's
line-interactive...
Regardless, backups are
Hi,
>(Second bricked SSD in 12
>months)
>A *very* short power shortage crept under my APC UPS and >bricked the SSD.
I wonder: did bricked SSD problem happened to anyone else
reading this message?
And a question: I don't know much about UPS and electricity, but would
a protector like the following
> It's a 180Gb Intel 520 Series SSD with firmware version 400i.
...
> I have an ext4 filesystem on it.
Semi-OT: A word of friendly warning:
I recently bricked a 120GB Intel 520 w/ the latest firmware (not sure
if it was 400i) w/ ext4 on Fedora 17/x86_64. (Second bricked SSD in 12
months)
A *very*
On Sun, Dec 30, 2012 at 7:37 PM, Dan Shimshoni wrote:
> Thanks!
>
> Which File System do you have on your SSD, if I may ask ?
>
>
Note that this is unrelated to the hdparm benchmark, which was on the
device, and not through the filesystem layer :)
# mount | grep sda2
/dev/sda2 on / type ext4 (r
n it.
> DS
>
Lior
>
> On Sun, Dec 30, 2012 at 8:45 AM, Lior Okman wrote:
> >
> >
> >
> > On Sun, Dec 30, 2012 at 6:26 AM, Dan Shimshoni
> wrote:
> >>
> >> Hi,
> >>
> >> 2 Questions about SSD drives:
> >>
> &
Thanks!
Which File System do you have on your SSD, if I may ask ?
DS
On Sun, Dec 30, 2012 at 8:46 AM, shimi wrote:
>
>
>
> On Sun, Dec 30, 2012 at 6:26 AM, Dan Shimshoni wrote:
>>
>> Hi,
>>
>> 2 Questions about SSD drives:
>>
>> First, I w
Lior,
- Can you please specify vendor and model of your SSD drive ?
second - which File System do you have on it ?
DS
On Sun, Dec 30, 2012 at 8:45 AM, Lior Okman wrote:
>
>
>
> On Sun, Dec 30, 2012 at 6:26 AM, Dan Shimshoni wrote:
>>
>> Hi,
>>
>> 2 Questi
On Sun, Dec 30, 2012 at 8:46 AM, shimi wrote:
>
> I really don't think so. SSDs (IMHO) makes computer much faster due to the
> VERY low seek time - the time it takes you to get a block. Compare 10-20ms
> with ~0.1ms. A regular hard drive simply wastes a lost of time seeking the
> data, instead of.
On Sun, Dec 30, 2012 at 6:26 AM, Dan Shimshoni wrote:
> Hi,
>
> 2 Questions about SSD drives:
>
> First, I would appreciate of someone who has SSD disk will
> run
> hdparm -t /dev/sda
> and post the results here. (In the spirit of the recent thread about
> HW for li
On Sun, Dec 30, 2012 at 6:26 AM, Dan Shimshoni wrote:
> Hi,
>
> 2 Questions about SSD drives:
>
> First, I would appreciate of someone who has SSD disk will
> run
> hdparm -t /dev/sda
> and post the results here. (In the spirit of the recent thread about
> HW for li
Hi,
2 Questions about SSD drives:
First, I would appreciate of someone who has SSD disk will
run
hdparm -t /dev/sda
and post the results here. (In the spirit of the recent thread about
HW for linux).
I have
/dev/sda:
Timing buffered disk reads: 586 MB in 3.01 seconds = 194.68 MB/sec
And it
40 matches
Mail list logo