Now the crackpots are trying to make it their own

G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Right on the heels of that grad student making his announcement about
Hyperthreading vulnerability, the crackpots calling themselves experts
are expounding all of their worthless opinions. The following guy thinks
that the dual-core processors have shared caches. None of the CPUs do so
far, but that doesn't stop an "expert" from fommenting panic about it.

> Ronald Rivest, cryptographer and professor of computer science at MIT, observed that dual-core and symmetrical multithreading (SMT) processors all use a shared on-chip cache.

Expert warns of attacks on dual-core processors - vnunet.com
http://www.vnunet.com/2135349

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On 2005-05-18 22:18:19 -0500, Yousuf Khan <bbbl67@ezrs.com> said:

> Right on the heels of that grad student making his announcement about
> Hyperthreading vulnerability, the crackpots calling themselves experts
> are expounding all of their worthless opinions. The following guy
> thinks that the dual-core processors have shared caches. None of the
> CPUs do so far, but that doesn't stop an "expert" from fommenting panic
> about it.
>
>> Ronald Rivest, cryptographer and professor of computer science at MIT,
>> observed that dual-core and symmetrical multithreading (SMT) processors
>> all use a shared on-chip cache.
>
> Expert warns of attacks on dual-core processors - vnunet.com
> http://www.vnunet.com/2135349

POWER4 and POWER5 have shared L2.

I'd hardly call Rivest a crackpot, but I agree that he's doing the
public a disservice by jumping on the "shared cache is the end of the
world" bandwagon. The real problem is the "standard" crypto mindset,
which is roughly:

no known attacks == secure
one impractical attack == totally broken, run for the hills

The last time we saw this in action was when SHA-1 was cracked.

--
Wes Felter - wesley@felter.org - http://felter.org/wesley/
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

He is 'R' in RSA, if it tells you anything.

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:aATie.6512$dS3.837926@news20.bellglobal.com...
> Right on the heels of that grad student making his announcement about
> Hyperthreading vulnerability, the crackpots calling themselves experts are
> expounding all of their worthless opinions. The following guy thinks that
> the dual-core processors have shared caches. None of the CPUs do so far,
> but that doesn't stop an "expert" from fommenting panic about it.
>
>> Ronald Rivest, cryptographer and professor of computer science at MIT,
>> observed that dual-core and symmetrical multithreading (SMT) processors
>> all use a shared on-chip cache.
>
> Expert warns of attacks on dual-core processors - vnunet.com
> http://www.vnunet.com/2135349
>
> Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Wes Felter wrote:
> no known attacks == secure
> one impractical attack == totally broken, run for the hills
>
> The last time we saw this in action was when SHA-1 was cracked.

SHA-1 isn't really cracked imho, but it might be straining a bit.

AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack reduces
the complexity of finding a collision by a factor of 2000, i.e. 11 bits.

If this is correct, then SHA-1 is 'only' equivalent to a 149-bit secure
hash now, which is still enough to let me sleep well for a few more years.

Remember, the MD5 alternative starts with 'just' 128 bits, and this is
now 'totally broken', in that it has become possible to construct two
messages with the same hash, using a 64-bit meet-in-the-middle approach.

This means that even for MD5 it is still _very_ hard to take a given
message and spoof it by constructing another message that still reads
out like natural language or a valid gzip compression stream!

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <2005051823384516807%wesley@felterorg>,
Wes Felter <wesley@felter.org> wrote:
>
>I'd hardly call Rivest a crackpot, but I agree that he's doing the
>public a disservice by jumping on the "shared cache is the end of the
>world" bandwagon. The real problem is the "standard" crypto mindset,
>which is roughly:
>
>no known attacks == secure
>one impractical attack == totally broken, run for the hills

That's why I attempted to trim the sci.crypt group on my first post
to this thread in comp.arch. It basically degenerated into what
turned out to be a redundant but potentially useful debate over
risk management.

I still don't really see this as a crypto issue per se but a
memory protection issue. All memory used by a user process,
cached or not, should only be visible to that process and
the kernel if required. Timing issues still exist, but
nothing should be shared from the user perspective unless
it's explicitly shared. Covert channels can still be
established through cooperative processes using timing,
but the bandwidth of these should be restricted in secure
multiuser systems.

The notion of keeping "users" off web services servers is
well taken, and avoids many of these vulnerabilities since
"users" should not be allowed to execute arbitrary code
on these servers or to reliably sequence execution of
known code upon demand.

Perhaps IBM has the right idea with using cryptographic
coprocessors in z/Systems. Some earlier workstation class
systems like the Sun 3/60 used to have optional cryptographic
coprocessors, but these disappeared as CPU capacity grew.

Others have pointed out that the way common cryptographic
functions are implemented may be suboptimal and different
implementations might reduce vulnerability, though this is
not a solution to the potential for inadvertent memory
sharing/visibility between user processes.

Shared cache, like SMP RAM, should not mean that any
user process can "see" any storage it doesn't own.
Any period where that ownership is ambiguous should
be private to the CPU hardware or the OS kernel and
not visible to any user process.

Such problems seem to me a design flaw and not a
cryptography issue. They transcend cryptography in the
sense that more than cryptographic keys may be compromised,
and they should not be addressed by additional layers of
cryptographic security through obscurity.

You can't corral cattle if the calves can slip through
gaps in the fence.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Yousuf Khan wrote:

> Right on the heels of that grad student making his announcement about
> Hyperthreading vulnerability, the crackpots calling themselves experts
> are expounding all of their worthless opinions. The following guy thinks
> that the dual-core processors have shared caches. None of the CPUs do so
> far, but that doesn't stop an "expert" from fommenting panic about it.
>
>> Ronald Rivest, cryptographer and professor of computer science at MIT,
>> observed that dual-core and symmetrical multithreading (SMT)
>> processors all use a shared on-chip cache.

Did you just call Ronald Rivest a crackpot?!?

http://en.wikipedia.org/wiki/Rivest
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <d6hff1$sf6$1@news-rocq.inria.fr>,
Grumble <devnull@kma.eu.org> wrote:
>
>Yousuf Khan wrote:
>
>> Right on the heels of that grad student making his announcement about
>> Hyperthreading vulnerability, the crackpots calling themselves experts
>> are expounding all of their worthless opinions. The following guy thinks
>> that the dual-core processors have shared caches. None of the CPUs do so
>> far, but that doesn't stop an "expert" from fommenting panic about it.
>>
>>> Ronald Rivest, cryptographer and professor of computer science at MIT,
>>> observed that dual-core and symmetrical multithreading (SMT)
>>> processors all use a shared on-chip cache.
>
>Did you just call Ronald Rivest a crackpot?!?

Such would seem uncalled for in this case.

OTOH, the fact that one is an acknowledged expert does not grant
infallibility.

Linus Pauling did publish a hastily retracted paper proposing a
rather elaborate triple helix structure for DNA which appeared
to match the then available X-ray diffraction data but had the
embarrassing characteristic of chemically not being an acid.

In this case Rivest appears to have a valid point if it proves
possible for user processes to examine cache regions they should
not own at that moment. Panic may not be warranted unless users
can execute arbitrary code on demand, but interactive input
channels could permit exploitation through carefully designed
inputs from simultaneous connections in some cases.

Given the well publicized timing attacks on MULTICS (which the
Air Force used in multilevel secure mode for years despite
knowing this vulnerability), one would think contemporary
designers would be more sensitive to these issues.

Processor cores should be able to share cache without user
processes being able to do so absent explicit arrangements.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Grumble wrote:
> Did you just call Ronald Rivest a crackpot?!?
>
> http://en.wikipedia.org/wiki/Rivest

Yes, I did, because quite clearly his field isn't processor
architecture. Most dual-cores do not have any shared cache. He took a
vulnerability specific to multithreading, and extended it out to
dual-cores quite cavalierly. And the fact that he's an expert in a
somewhat related field of computer cryptography, people are going to
think he knows what he's talking about here and start panicking.

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
> Wes Felter wrote:
> > no known attacks == secure
> > one impractical attack == totally broken, run for the hills
> >
> > The last time we saw this in action was when SHA-1 was cracked.
>
> SHA-1 isn't really cracked imho, but it might be straining a bit.
>
> AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack reduces
> the complexity of finding a collision by a factor of 2000, i.e. 11 bits.
>
> If this is correct, then SHA-1 is 'only' equivalent to a 149-bit secure
> hash now, which is still enough to let me sleep well for a few more years.

The worry is not that an attack on SHA has been found, but rather once
one attack is found crytpo-types are pretty good at finding more.
Once one weakness is found in a cryptosystem grad students hammer it
from all sides, and often the manage to widen the cracks and break the
whole thing open. (My fiancee is a cryptography grad student -- I
have seen this in action. :) )

So no, it is not broken to the point of uselessness. Yet. But
history teaches us that it likely will be, soon.

Chris
--
Chris Colohan Email: chris@colohan.ca PGP: finger colohan@cs.cmu.edu
Web: www.colohan.com Phone: (412)268-4751
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <ucl64xf8axi.fsf@cilento.stampede.cs.cmu.edu>,
Chris Colohan <colohan+@cs.cmu.edu> writes:
|> Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
|> >
|> > SHA-1 isn't really cracked imho, but it might be straining a bit.
|> >
|> > AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack reduces
|> > the complexity of finding a collision by a factor of 2000, i.e. 11 bits.
|> >
|> > If this is correct, then SHA-1 is 'only' equivalent to a 149-bit secure
|> > hash now, which is still enough to let me sleep well for a few more years.
|>
|> The worry is not that an attack on SHA has been found, but rather once
|> one attack is found crytpo-types are pretty good at finding more.
|> Once one weakness is found in a cryptosystem grad students hammer it
|> from all sides, and often the manage to widen the cracks and break the
|> whole thing open. (My fiancee is a cryptography grad student -- I
|> have seen this in action. :) )
|>
|> So no, it is not broken to the point of uselessness. Yet. But
|> history teaches us that it likely will be, soon.

Hmm. Can you provide any clear examples? Yes, I know that it
applies to new gimmicks, which last until someone spots their
flaws, but DES, SHA etc. aren't like that. Weaknesses in DES
have been known for ages, but there is no way that it has been
"cracked open".

The same thing applies to statistical pseudorandom number generators.
Both multiplicative congruential and shift register have had known
weaknesses for 35 years, but are still reliable when used correctly.


Regards,
Nick Maclaren.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <1116523369.416700.241950@z14g2000cwz.googlegroups.com>,
YKhan <yjkhan@gmail.com> wrote:
>
>Yes, I did, because quite clearly his field isn't processor
>architecture. Most dual-cores do not have any shared cache. He took a
>vulnerability specific to multithreading, and extended it out to
>dual-cores quite cavalierly. And the fact that he's an expert in a
>somewhat related field of computer cryptography, people are going to
>think he knows what he's talking about here and start panicking.

Well, then, what do you think about simply splitting the cache
among cores? It really depends on how workload gets allocated.

If each core ends up with a roughly equivalent working set of
cached storage, why bother with an elaborate protection scheme
when you can just split and firewall it?

OTOH, if there is significant variation in cacheable working
memory over reasonable timeframes that can be effectively exploited
to speed up the CPU to more than offset the cost of developing a more
elegant memory protection solution, so be it.

I still don't see what this has to do directly with cryptography.
Cryptographic keys are just another element of data which might
be compromised, perhaps not the most valuable. OTOH, it seems
absurd to project another level of encryption whenever one finds
a resource sharing vulnerability. It kind of reminds me of the
story where someone was riding around the Disneyland parking
lot in a security vehicle clicking the keyfob for the rental car
they lost.
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Thu, 19 May 2005 16:09:43 +0000, Nick Maclaren wrote:

>
> In article <ucl64xf8axi.fsf@cilento.stampede.cs.cmu.edu>,
> Chris Colohan <colohan+@cs.cmu.edu> writes:
> |> Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
> |> >
> |> > SHA-1 isn't really cracked imho, but it might be straining a bit.
> |> >
> |> > AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack reduces
> |> > the complexity of finding a collision by a factor of 2000, i.e. 11 bits.
> |> >
> |> > If this is correct, then SHA-1 is 'only' equivalent to a 149-bit secure
> |> > hash now, which is still enough to let me sleep well for a few more years.
> |>
> |> The worry is not that an attack on SHA has been found, but rather once
> |> one attack is found crytpo-types are pretty good at finding more.
> |> Once one weakness is found in a cryptosystem grad students hammer it
> |> from all sides, and often the manage to widen the cracks and break the
> |> whole thing open. (My fiancee is a cryptography grad student -- I
> |> have seen this in action. :) )
> |>
> |> So no, it is not broken to the point of uselessness. Yet. But
> |> history teaches us that it likely will be, soon.
>
> Hmm. Can you provide any clear examples? Yes, I know that it
> applies to new gimmicks, which last until someone spots their
> flaws, but DES, SHA etc. aren't like that. Weaknesses in DES
> have been known for ages, but there is no way that it has been
> "cracked open".

What "weakness" in DES (other than keylength == brute force)?

--
Keith
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"keith" <krw@att.bizzzz> wrote in message
news:pan.2005.05.20.02.19.21.707759@att.bizzzz...
> On Thu, 19 May 2005 16:09:43 +0000, Nick Maclaren wrote:
>
>>
>> In article <ucl64xf8axi.fsf@cilento.stampede.cs.cmu.edu>,
>> Chris Colohan <colohan+@cs.cmu.edu> writes:
>> |> Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
>> |> >
>> |> > SHA-1 isn't really cracked imho, but it might be straining a bit.
>> |> >
>> |> > AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack
>> reduces
>> |> > the complexity of finding a collision by a factor of 2000, i.e. 11
>> bits.
>> |> >
>> |> > If this is correct, then SHA-1 is 'only' equivalent to a 149-bit
>> secure
>> |> > hash now, which is still enough to let me sleep well for a few more
>> years.
>> |>
>> |> The worry is not that an attack on SHA has been found, but rather once
>> |> one attack is found crytpo-types are pretty good at finding more.
>> |> Once one weakness is found in a cryptosystem grad students hammer it
>> |> from all sides, and often the manage to widen the cracks and break the
>> |> whole thing open. (My fiancee is a cryptography grad student -- I
>> |> have seen this in action. :) )
>> |>
>> |> So no, it is not broken to the point of uselessness. Yet. But
>> |> history teaches us that it likely will be, soon.
>>
>> Hmm. Can you provide any clear examples? Yes, I know that it
>> applies to new gimmicks, which last until someone spots their
>> flaws, but DES, SHA etc. aren't like that. Weaknesses in DES
>> have been known for ages, but there is no way that it has been
>> "cracked open".
>
> What "weakness" in DES (other than keylength == brute force)?

There are the weak and semi-weak keys, but these are well known, easy to
avoid, and havent led to more attacks.

--
- Stephen Fuld
e-mail address disguised to prevent spam
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <R8nje.797001$w62.573299@bgtnsc05-
news.ops.worldnet.att.net>, s.fuld@PleaseRemove.att.net says...
>
> "keith" <krw@att.bizzzz> wrote in message
> news:pan.2005.05.20.02.19.21.707759@att.bizzzz...
> > On Thu, 19 May 2005 16:09:43 +0000, Nick Maclaren wrote:
> >
> >>
> >> In article <ucl64xf8axi.fsf@cilento.stampede.cs.cmu.edu>,
> >> Chris Colohan <colohan+@cs.cmu.edu> writes:
> >> |> Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
> >> |> >
> >> |> > SHA-1 isn't really cracked imho, but it might be straining a bit.
> >> |> >
> >> |> > AFAIR SHA-1 employs 20-byte (160-bit) hashes, while the attack
> >> reduces
> >> |> > the complexity of finding a collision by a factor of 2000, i.e. 11
> >> bits.
> >> |> >
> >> |> > If this is correct, then SHA-1 is 'only' equivalent to a 149-bit
> >> secure
> >> |> > hash now, which is still enough to let me sleep well for a few more
> >> years.
> >> |>
> >> |> The worry is not that an attack on SHA has been found, but rather once
> >> |> one attack is found crytpo-types are pretty good at finding more.
> >> |> Once one weakness is found in a cryptosystem grad students hammer it
> >> |> from all sides, and often the manage to widen the cracks and break the
> >> |> whole thing open. (My fiancee is a cryptography grad student -- I
> >> |> have seen this in action. :) )
> >> |>
> >> |> So no, it is not broken to the point of uselessness. Yet. But
> >> |> history teaches us that it likely will be, soon.
> >>
> >> Hmm. Can you provide any clear examples? Yes, I know that it
> >> applies to new gimmicks, which last until someone spots their
> >> flaws, but DES, SHA etc. aren't like that. Weaknesses in DES
> >> have been known for ages, but there is no way that it has been
> >> "cracked open".
> >
> > What "weakness" in DES (other than keylength == brute force)?
>
> There are the weak and semi-weak keys, but these are well known, easy to
> avoid, and havent led to more attacks.

Well, these were known to the DES developers. ...not exactly a
"weakness", IMO. It's rather like telling one that an XOR of all zeros
is uninteresting.

--
Keith

>
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Calling Rivest a crackpot is nearly as bad as invoking Godwin's Law.
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Sat, 21 May 2005 00:08:28 +0000, Taenia Solium wrote:

>
> Calling Rivest a crackpot is nearly as bad as invoking Godwin's Law.

*I* never said anything of the kind (though he did fly off the handle on
this one). Wasn't Rivest the one that jumped all over the DES
differential cryptanalysis "hole" back about '90?

--
Keith
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

keith wrote:
> On Sat, 21 May 2005 00:08:28 +0000, Taenia Solium wrote:
>
>
>>Calling Rivest a crackpot is nearly as bad as invoking Godwin's Law.
>
>
> *I* never said anything of the kind (though he did fly off the handle on
> this one). Wasn't Rivest the one that jumped all over the DES
> differential cryptanalysis "hole" back about '90?

Now, the *professional* crackpots have joined the feeding frenzy,
otherwise known as analyst firms.

Prepare for the Threat of Timing Attacks
http://www.gartner.com/DisplayDocument?doc_cd=127924

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
> Now, the *professional* crackpots have joined the feeding frenzy,
> otherwise known as analyst firms.
>
> Prepare for the Threat of Timing Attacks
> http://www.gartner.com/DisplayDocument?doc_cd=127924

And, predictably, they completely missed the point.

Gartner writes:
>>> Do not keep intermediate results, keys or passwords in memory.

A good idea, but irrelevant to this attack.

>>> Design cryptographic algorithms to reveal nothing through simple
>>> timing attacks.

A good idea, but fails to recognize that my attack can also obtain
information from non-cryptographic processes which use non-oblivious
algorithms. Cryptography is a big target, but certainly not the only
one.

>>> "Prepare for the Arrival of Dual-Core Processors"

Completely irrelevant. Dual-core processors are no more affected by this
than single-core processors, and far less than hyperthreaded processors.

Colin Percival
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <pan.2005.05.20.02.19.21.707759@att.bizzzz>,
keith <krw@att.bizzzz> wrote:
>
>What "weakness" in DES (other than keylength == brute force)?

The social engineer who needs your personal information to
"verify" your account...
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <87zmupcuen.fsf@kafka.homenet>,
Taenia Solium <rambam@bigpond.net.au> wrote:
>
>Calling Rivest a crackpot is nearly as bad as invoking Godwin's Law.

Calling him an authority without critically evaluating his arguments
about the matter at hand could be worse. Evaluating his experience
is not irrelevant, though.

OTOH, It seems to me that most of the posts about this issue have
failed to take into account rational risk management, and a politically
correct society where every argument immediately descends into
namecalling and never rises back above it after the parties get over
their intellectual hangovers. This is the antithesis of science.

We live in a society where Tom Bearden can get a patent on his
"motionless electromagnetic generator" which is nothing more than
a transformer with a permanent magnet embedded in the core, because
criticizing an "expert" is unthinkable.
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Sun, 22 May 2005 04:45:41 +0000, Colonel Forbin wrote:

> In article <pan.2005.05.20.02.19.21.707759@att.bizzzz>,
> keith <krw@att.bizzzz> wrote:
>>
>>What "weakness" in DES (other than keylength == brute force)?
>
> The social engineer who needs your personal information to
> "verify" your account...

Ok, you got me. What weakness in DES does that expose? A potential
security weakness, sure.

--
Keith
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Tom Linden" <tom@kednos.com> writes:
> Can the cache be shared by separate processes?

ugh ... nearly 40 years ago as an undergraudate
.. .. i started doing a bunch of work on page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
on multi-user timesharing systems
http://www.garlic.com/~lynn/subtopic.html#timeshare
that was being turned around and shipped in commercial systems,
actually, i was also doing the generalized resource scheduling
algorithms that also were being shipped in commercial systems
http://www.garlic.com/~lynn/subtopic.html#fairshare

.... anyway ... I was asked several times about the problem of
low-bandidth information leakage and what was I going to do about it.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Colin Andrew Percival wrote:
>>>>"Prepare for the Arrival of Dual-Core Processors"
>
>
> Completely irrelevant. Dual-core processors are no more affected by this
> than single-core processors, and far less than hyperthreaded processors.

What's that Gartner said about Intel being able to demonstrate this
attack even on single-threaded processors? It seems nearly impossible to
do this with only one thread running at a time.

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Sun, 22 May 2005 12:37:15 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:

> Colin Andrew Percival wrote:
>>>>> "Prepare for the Arrival of Dual-Core Processors"
>> Completely irrelevant. Dual-core processors are no more affected by
>> this than single-core processors, and far less than hyperthreaded
>> processors.
>
> What's that Gartner said about Intel being able to demonstrate this
> attack even on single-threaded processors? It seems nearly impossible to
> do this with only one thread running at a time.
>
Can the cache be shared by separate processes?

> Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Colin Andrew Percival" <cperciva@sfu.ca> wrote in message
news:d6ov9j$g11$1@morgoth.sfu.ca...
> In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
>> Now, the *professional* crackpots have joined the feeding frenzy,
>> otherwise known as analyst firms.
>>
>> Prepare for the Threat of Timing Attacks
>> http://www.gartner.com/DisplayDocument?doc_cd=127924
>
> And, predictably, they completely missed the point.
>
> Gartner writes:
>>>> Do not keep intermediate results, keys or passwords in memory.
>
> A good idea, but irrelevant to this attack.
>
>>>> Design cryptographic algorithms to reveal nothing through simple
>>>> timing attacks.
>
> A good idea, but fails to recognize that my attack can also obtain
> information from non-cryptographic processes which use non-oblivious
> algorithms. Cryptography is a big target, but certainly not the only
> one.
>
>>>> "Prepare for the Arrival of Dual-Core Processors"
>
> Completely irrelevant. Dual-core processors are no more affected by this
> than single-core processors, and far less than hyperthreaded processors.

While I agree with the general tenor of your post, ISTM that a dual core
processor that shares cache at some level (some existing designs do), is as
vulnerable as a hyperthreaded processor. To be precise, you should talk
about a vulnerability where multiple processes/cores simultaneously share
caches, not specifically of hyperthreading.

--
- Stephen Fuld
e-mail address disguised to prevent spam