![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 10 Jul 2009 13:37:36 -0400, Warp wrote:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jim Henderson wrote:
> On Fri, 10 Jul 2009 13:37:36 -0400, Warp wrote:
>
>> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |