Hacker News Reader

Comment by zobzu | Hacker News Reader

-----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (GNU/Linux)

hQEMA/H221DfyGXJAQf+IDMe33H8hz1MgYfqxGta/FauUinOWtXqT+xskkGtt+es wRE1stgcJeKlzFDMHMS99Cvfw1qUis+CMVUnrBJw3yn1tdNo3FV+V0BgMIJwTPGS nkHxeXsxHXcsgcyRhB1PEO2arPaiek9xqxwUehnsDHI8T6oAJaUhteNHo72ybM4S Q1vSY8/Ni6t7Uk5zjpsHPq+Jhi7+QA9L1xaJuNBcm1lQxE2hWyrdXRB7N+HMnvJR LMgZndBjoKeui032cbIV8z/N7n2YT8Vtx0syVkDT0KppcW4EcQyAp6hbRPrgnUMu jDLLwT1xSgPwtH8NPo0iuusGmONa+stGGmjwHnhiLNJxAZWGQM36uE+FA9bXUVDl ikp29kE8qmCijPIHSDUny6SiNUjrEJeQEBq4TJpU7GDEsOQKx2tjchOZyWQFpKWK mBPnU6H9uAAByM+t+ejG5lxxlp/R9eKBs+YSf7QT7H2sLR/KIwyuXNJg+oHBtzKY weo= =bZbG -----END PGP MESSAGE-----

View on HN

So how do we read it?

Edit: I know public key crypto... I meant: where's the key?

You need his public key to decrypt it.

I think you mean private key. If it were public key it would not be secure at all :)

No. You need his public key. His private key should be known only by him. That said, he also needed the recipients public key to encrypt it.

Private keys are private. Public keys are public.

Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.

>Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.

Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.

Likewise, for the recipient to decrypt, they only need their private key. No need for the encryptor's public key.

You can send messages to other PGP users without ever creating your own keypair. It's only to receive encrypted messages that you need a keypair.

Now, if you want to sign a message that you're sending, you need a keypair.

> Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.

I don't think this is right. The diagram here appears to depict otherwise: https://en.wikipedia.org/wiki/File:Public_key_shared_secret....

No. This diagram is depicting the creation of a shared secret for symmetric communication. PGP is asymmetric.

I tell you what. Do you have a PGP keypair? Post your public key here (the one you would host on a public keyserver) and I'll show you a short script that can encrypt information that only you can read using your private key. It will use no other keypair besides your own public key.

You seem to be using encrypt/decrypt interchangeably. You had said:

> You need his public key to "decrypt" it.

My correction assumed that you had made a typo when you said "decrypt".

Also you only need the recipients public key to encrypt the message. [0]

[0] http://www.pgpi.org/doc/pgpintro/

The rule: A message encrypted with a private key can only be decrypted using the corresponding public key. A message encrypted with a public key can only be decrypted using the corresponding private key.

If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.

Why would anyone do this? Because it is a way to verify that the message came from a specific person or group. If you can decrypt a message with a given public key, you know "Only the people who have access to the corresponding private key could have published this message." You don't necessarily know who, in specific published it, but you can do things like determining that a batch of messages all came from the same group.

Now, if the person had encrypted it with a specific person's public key, then only that specific person would be able to decrypt it, because messages encrypted with a public key can only be decrypted with the corresponding private key. Being able to post private messages in public fora without needing to meet the recipient beforehand is one of the main features of public-key cryptography.

> If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.

That's really interesting, I had no idea that public key encryption could be used this way.

That's how signing works. The signer generates a hash of the content being signed, and then encrypts that hash with their own private key. Then anyone with the public key can decrypt the hash, and then compare the decrypted hash against the hash of the content that they generate themselves.

I am not sure whether this is literally possible or not, but it doesn't make a lot of sense. Sending an encrypted message with the decryption key right along side or otherwise in public view?

The common use case is to _sign_ with a private key and _verify_ with the public key. If you need the contents of the message to be secret, you can use other methods. The signature proves something about the authorship of the original message.

For example, if someone wished to make a prediction about the future, they might write down the prediction, sign it with a private key, but then only publish the signature. Later, when the prediction turns out to be true (or false), they publish the original text. The public key can then verify that the precise text of the original prediction created the previously published signature.

edit: in this case, zobzu might have created a one-use private key, encrypted a prediction about DNSNMC with the corresponding public key, and will later publish that private key. Or it might be the output of /dev/urandom

So I can go find his public key on a keyserver and decrypt this message? Is that what you're asserting?

Author here: yes, support for GPG is one way of using @okTurtles (e.g. with OTR off).

Your comment would be instantly readable to whoever the intended recipient(s) are, with no manual intervention on their part. (see also reply 'rakoo': https://news.ycombinator.com/item?id=6963081)

What type of OTR improvements suggested by Trevor Perrin did you use. The same ones TextSecure will be using?

https://whispersystems.org/blog/advanced-ratcheting/

We're actively following the work of Trevor, Moxie, and all the great folks at Open WhisperSystems. Some of their work is cited and analyzed in the paper that's on the site. Of course I'd love to use and keep up with the best ideas, whatever they happen to be, and so one of the design goals of okTurtles is to be somewhat protocol-agnostic, so that it's easy to incorporate better ideas as they come along, while maintaining backwards compatibility. At the moment, TextSecure's example of async-OTR, with their modifications to make the protocol simpler (3 DHE, and the ratcheting you cite), seem quite appealing, and unless we find something better, we'll probably use that (with the exception that we won't be relying on a single centralized server).

Reply on news.ycombinator.com