[Cryptography] Speculation re Intel HW cockup; reqs. OS rewrites & slow execution

Stephen Farrell stephen.farrell at cs.tcd.ie
Fri Jan 5 22:34:37 EST 2018



On 05/01/18 19:55, Tom Mitchell wrote:
> It is not x86 but the design decisions to make their part execute code
> quickly.

I think this is the main point - ISTM that performance has been
seen as a way more important goal than security or privacy, and
the same is (IMO sadly) still true. (See TLS1.3 and 0rtt, albeit
that TLS1.3 is still an overall good thing.)

Given that difference in prioritisation, and the fact that many
designs were done before cache based side-channel attacks were
known, I don't think these attacks are much of a surprise really.
(They are of course excellent work though.)

More interesting for this list (or for me anyway:-) is whether
or not there are any implementation countermeasures open-source
s/w can take to better protect secret/private values if running
on a guest-OS alongside other potentially bad guests. Other than
obfuscating I'm not seeing many worthwhile avenues to explore,
but would love to hear if there are.

Cheers,
S.


-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x7B172BEA.asc
Type: application/pgp-keys
Size: 5950 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180106/82d12482/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180106/82d12482/attachment.sig>


More information about the cryptography mailing list