OK, so here's how it works:

You want to send a file to somebody securely over the Internet. 
Obviously the only way to do this is to encrypt it somehow. But 
presumably you'd like the person at the other end to be able to decrypt 
it, right?

But that's the problem, isn't it? You could just email them the 
encryption key along with the file... but then why did you bother 
encrypting the file? You could... I don't know... send the key in a 
seperate email? Hmm, but that doesn't help much. Or I guess you could 
send the key by post or read it over the phone or something...

In theory, even if you do one of these things, somebody might be reading 
your mail or tapping your phone. Absurdly unlikely, but possible. So, a 
bunch of mathematical geniuses came up with a system which neatly solves 
the whole problem: asymmetric encryption.

Essentially, instead of having one key, you have two. Anybody who has 
the encryption key can encrypt data, but they can't decrypt it. Anybody 
with the decryption key can decrypt data, but not encrypt it. And by 
carefully controlling who has access to which key(s), you can obtain 
security.

For example, if you want to send a file securely, get the intended 
recipient to build a pair of keys, and send you the encryption key only. 
You then encrypt your file with this encryption key, safe in the 
knowledge that the only person on Earth who knows what the hell the 
decryption key is just happens to be the person you're sending the file to.

You can use the same system backwards to provide authentication rather 
than security, and you can use several keys at once to gain 
authentication *and* security at the same time, for one or both 
endpoints, and so on. This is how systems such as HTTPS and SFTP work.

In particular, for something like SSH or SFTP, typically both you and 
the server you're trying to contact have a keypair, and server and 
client exchange only their public keys, keeping their private ones 
secret. So to set up an account on a given server, you generate a 
keypair and email the public key only to the server admin, who then sets 
up your account.

So what did *Pfizer Incorporated* just go and do? They generated a 
keypair on our behalf and emailled both of the keys to us in the clear, 
thus completely circumventing the entire purpose of asymmetric 
encryption. >_<

Why do I bother?

(I especially like the way they emailled the keys password-protected, 
with the password in the same email as the keys - even though the 
instructions say that they won't ever do this... Almost as amusing as 
the instructions being marked "draft" and dated March 2005...)

Post a reply to this message

Btw, one interesting application of assymetric encryption is adding
signatures to files.

  Only the person who owns the secret key can sign files in that particular
way. The trick that makes this useful is that anyone can check using this
person's public key whether the signature is genuine or not. It's impossible
(to current knowledge) for anyone to fake the signature, so anyone can check
that the file has been indeed signed by that person and be pretty certain
that it hasn't been tampered with. Also this doesn't impede retrieving the
data from the file (ie. the data itself is not encrypted in a way that would
disallow retrieving it).

  One practical usage of this is, as far as I know, the PlayStation Portable:
It's ROM will refuse to run anything that hasn't been signed by Sony, and
since it's impossible for anyone to fake this signature (even though anyone
can read the public key stored in the ROM), it's not possible to run user-made
programs. (Of course this hasn't stopped from people successfully doing that
anyways, but not by cracking the protection, but instead by exploiting
programming errors in other parts of the ROM. Anyways, the technique itself
is quite sound.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Btw, one interesting application of assymetric encryption is adding
> signatures to files.

You can add them to the file itself, or have them as a seperate file. 
(Useful if the application that reads whatever it is you're trying to 
sign doesn't "understand" signatures, but you still want to prove 
authenticity.)

And, indeed, this is what SFTP is using keys for; the actual data 
transit uses regular symmetric encryption, and a key can be securely 
agreed upon without asymmetric encryption (which is also pretty mental, 
BTW...)

>   Only the person who owns the secret key can sign files in that particular
> way. The trick that makes this useful is that anyone can check using this
> person's public key whether the signature is genuine or not. It's impossible
> (to current knowledge) for anyone to fake the signature, so anyone can check
> that the file has been indeed signed by that person and be pretty certain
> that it hasn't been tampered with.

The only glitch is proving that the thing is signed by who you think it is.

>   One practical usage of this is, as far as I know, the PlayStation Portable:
> It's ROM will refuse to run anything that hasn't been signed by Sony, and
> since it's impossible for anyone to fake this signature.

Some people are predicting that in the future, regular computers will 
work in this way, to prevent anybody running anything that can 
circumvent DRM.

Post a reply to this message

Warp wrote:
>   Btw, one interesting application of assymetric encryption is adding
> signatures to files.

When I was at Bellcore, there was a lot of cool research expanding this. 
They had for example what they called "face to face encryption." I could 
have an encrypted conversation with you, and I'd know 100% sure it was you, 
you'd know 100% sure it was me, but nobody outside the conversation could 
prove either of us had actually said anything, just like a face-to-face 
conversation. I can't prove you said anything in that conversation, and I 
might have made up the whole conversation from scratch, even if I give a 
judge the whole stream of conversation and every key I have. But I still 
know with certainty that it was you (or at least your key) on the other side 
of the conversation.

They also had a timestamping service, where hashes were chained together, 
and then published in (for example) the New York Times every couple of 
weeks, whereby you could prove that you'd had a certain piece of text at a 
certain point in time without revealing that text to the timestamp service.

Lots of cool stuff can be put together with layers of the basic primitives.

> It's ROM will refuse to run anything that hasn't been signed by Sony, and

The set-top box I'm using has the same thing. I have to sign every compile 
before the machine will boot. And there's separate chips for developers and 
production, so the developers can't get to the production keys. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Some people are predicting that in the future, regular computers will 
> work in this way, to prevent anybody running anything that can 
> circumvent DRM.

  Then Microsoft will have a huge party for having at last destroyed Linux
with its 3% market share.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 10 Jul 2009 13:37:36 -0400, Warp wrote:

> Invisible <voi### [at] devnull> wrote:
>> Some people are predicting that in the future, regular computers will
>> work in this way, to prevent anybody running anything that can
>> circumvent DRM.
> 
>   Then Microsoft will have a huge party for having at last destroyed
>   Linux
> with its 3% market share.

Right before they get their butts sued for anticompetitive behaviour 
(again). ;-)

Jim

Post a reply to this message

Jim Henderson wrote:
> On Fri, 10 Jul 2009 13:37:36 -0400, Warp wrote:
> 
>> Invisible <voi### [at] devnull> wrote:
>>> Some people are predicting that in the future, regular computers will
>>> work in this way, to prevent anybody running anything that can
>>> circumvent DRM.
>>   Then Microsoft will have a huge party for having at last destroyed
>>   Linux
>> with its 3% market share.
> 
> Right before they get their butts sued for anticompetitive behaviour 
> (again). ;-)

Last time I checked, Microsoft don't make PC hardware. Whoever controls 
the keys required to make the BIOS boot your OS would be sued if they 
only gave those keys to Microsoft and nobody else.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 11 Jul 2009 11:28:37 +0100, Orchid XP v8 wrote:

> Last time I checked, Microsoft don't make PC hardware. Whoever controls
> the keys required to make the BIOS boot your OS would be sued if they
> only gave those keys to Microsoft and nobody else.

It's very likely if that were to happen, collusion would be found - akin 
to price fixing (in a manner of speaking).  Trust me, someone would get 
their butt hauled into court over that.

Jim

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Some people are predicting that in the future, regular computers will 
>> work in this way, to prevent anybody running anything that can 
>> circumvent DRM.
> 
>   Then Microsoft will have a huge party for having at last destroyed Linux
> with its 3% market share.

I'm not sure you understand how TPM works. It doesn't keep you from running 
other OSes. It keeps you from running modified OSes that check their keys.

Basically, each stage of the boot sequence checks that the previous stage 
did what it expected: Once the boot ROM launches Windows, Windows checks 
that Windows checksums the way it thinks it should and checks that the boot 
ROM checksums the way it should.  That doesn't mean the boot ROM won't 
launch Linux.

Now, there *are* systems where the key is burned into the hardware, but TPM 
isn't one of them, as I understand it.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message