XKCD shows the real world of cryptography to the masses

[Matt Crawford]

Perry, I couldn't possibly be the first to pass along today's XKCD,  
could I?


http://xkcd.com/538/

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: full-disk subversion standards released

[Peter Gutmann]

Ben Laurie  writes:

>Apart from the obvious fact that if the TPM is good for DRM then it is also
>good for protecting servers and the data on them,

In which way, and for what sorts of "protection"?  And I mean that as a 
serious inquiry, not just a "Did you spill my pint?" question.  At the moment 
the sole significant use of TPMs is Bitlocker, which uses it as little more 
than a PIN-protected USB memory key and even then functions just as well 
without it.  To take a really simple usage case, how would you:

- Generate a public/private key pair and use it to sign email (PGP, S/MIME,
  take your pick)?
- As above, but send the public portion of the key to someone and use the
  private portion to decrypt incoming email?

(for extra points, prove that it's workable by implementing it using an actual
TPM to send and receive email with it, which given the hit-and-miss
functionality and implementation quality of TPMs is more or less a required
second step).  I've implemented PGP email using a Fortezza card (which is
surely the very last thing it was ever intended for), but not using a TPM...

>Mark Ryan presented a plausible use case that is not DRM:
>http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/.

This use is like the joke about the dancing bear, the amazing thing isn't the 
quality of the "dancing" but the fact that the bear can "dance" at all :-).  
It's an impressive piece of lateral thinking, but I can't see people rushing 
out to buy TPM-enabled PCs for this.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Obama's secure PDA

[Ivan Krstić]

On Jan 29, 2009, at 11:17 PM, Ivan Krstić wrote:
I'd find mobile e-mail just as useful if it went through a proxy  
that stripped out _everything_ that's not plaintext. I open  
attachments on my phone about once in a blue moon, and wouldn't miss  
the ability if it were gone.


As a postscript, it appears this type of proxy is exactly what's been  
set up:


"To minimize the risk, the government technology gurus
 have made it impossible to forward e-mail messages from
 the president or to send him attachments, people
 informed about the precautions say."
 -- 

--
Ivan Krstić  | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: full-disk subversion standards released

[Jonathan Thornburg]

I wrote:
| Indeed, the classic question is "I've just bought this new computer
| which claims to have full-disk encryption.  Is there any practical
| way I can assure myself that there are (likely) no backdoors in/around
| the encryption?"
| 
| For open-source software encryption (be it swap-space, file-system,
| and/or full-disk), the answer is "yes":  I can assess the developers'
| reputations, I can read the source code, and/or I can take note of
| what other people say who've read the source code.

On Fri, 30 Jan 2009, Brian Gladman asked:
> But, unless you are doing it with a pencil and paper, your encryption is still
> being done in hardware even if you write it yourself.
> 
> For example, why would you trust an Intel processor given that Intel is one of
> the founding members of the TCG and is a major player in its activities?

It's instructive to the distinction between "data in motion" encryption
(for example, a network-encryption-box (NEB) and "data at rest" encryption
(for example, a cryptographic filesystem):


A network-encryption box:

computer#1 <> NEB#1 <> ((network)) <> NEB#2 <> computer#2
  plaintextciphertext ciphertext   plaintext

As described by Henry Spencer in
  http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
it's perfectly practical for (say) the NSA to arrange for a backdoor
in each NEB which occasionally leaks the keystream into the network,
in a way that's very unlikely to be caught in testing, but would make
it easy for an eavesdropper on the network to recover the plaintext.


A cryptographic filesystem:

I could imagine the NSA having arranged to plant some sort of microcode
backdoor in the Pentium III processor in my laptop.  (The hardest part
would probably be persuading all the Intel employees involved that it
wouldn't be a PR disaster for Intel if the news leaked out.)  In the
context of my original message, the backdoor would have to recognize
the binary code sequence of the OpenBSD AES routines when invoked by
the encrypting-filesystem vnode layer, and somehow compromise the
security (maybe arrange to leak keystream bits into free disk sectors??).
That's a tricky technical job, but I could imagine it being done, and
if it's all in processor microcode, I could even imagine it having
stayed a secret.

But that's not good enough:  What about Matt Blaze's Cryptographic File
System?  What about all the people using the various Linux encrypting
file systems?  The backdoor(s) need to cover them, too.  And the MacOS
ones (if there's not a software backdoor there).  And all the other
open-source-crypto systems.  And the backdoors have to do this without
compromising interoperability -- I have CFS directory trees which I
created on an old Sparc that I now use on my laptop.

But I think the hardest part of all is that the backdoor has to still
still recognize the various crypto binary-code-sequences even when the
relevant software is recompiled with a newer compiler using a different
global optimizer, even though that newer compiler might not even have
existed when the backdoor was inserted.

It's this variety of different software encryption schemes -- and
compilers to turn them into binary code (which is what the NSA/Intel
backdoor ultimately has to key on) that, I think, makes it so much
harder for a hardware backdoor to work (i.e. to subvert software
encryption) in this context.

-- 
-- "Jonathan Thornburg [remove -animal to reply]" 

   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
  -- quote by Freire / poster by Oxfam

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com