Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards Sequoia OpenPGP v1.0

sequoia-pgp.org

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Towards Sequoia OpenPGP v1.0

#51

Post by upofadown »

tptacek wrote: post #48
upofadown wrote: post #32

Earlier quoted context omitted.

My best guess is that they really meant EFAIL but didn't want to actually mention it because EFAIL had nothing to do with any weakness in the OpenPGP standard or the GnuPG implementation. Instead it was a HTML email horror story where someone figured out how to forward entire decrypted messages using image links. So just more pointless anti-PGP innuendo...

That is not in fact a good description of EFail, which was indeed caused by a failure both of the PGP protocol and of GPG, its reference implementation.

>...a failure both of the PGP protocol ...

No. There were some changes in the actual protocol document that came out of EFAIL but no actual changes to the protocol other than a depreciation that was happening anyway.

>...and of GPG, ...

This also seems to be false. GPG didn't have to change anything as the result of EFAIL...

>...its reference implementation.

Also false. OpenPGP does not have a reference implementation.

Re: Towards Sequoia OpenPGP v1.0

#52

Post by forgotmypw16 »

GTP wrote: post #43
forgotmypw16 wrote: post #35

Earlier quoted context omitted.

The private key is stored in localStorage, but this is not the user's "real" private key which they might use for email, but a temporary device key, which can then be vouched either by admin or by user.

I'm not understanding how this works, then. Are you using the user's private key to somehow derive temporary device keys?

Generate a PGP key using in-browser JS. Use that key submitted posts.

Then, later, sign either the file hashes or the public key itself using actual secure PGP. This is optional.

I'm not claiming any level of security, this is all mostly UI prototyping.

Re: Towards Sequoia OpenPGP v1.0

#53

Post by tptacek »

upofadown wrote: post #51
tptacek wrote: post #48

Earlier quoted context omitted.

That is not in fact a good description of EFail, which was indeed caused by a failure both of the PGP protocol and of GPG, its reference implementation.

>...a failure both of the PGP protocol ... No. There were some changes in the actual protocol document that came out of EFAIL but no actual changes to the protocol other than a depreciation that was happening anyway. >...and of GPG, ... This also seems to be false. GPG didn't have to change anything as the result of EFAIL... >...its reference implementation. Also false. OpenPGP does not have a reference implementatio…

There were no changes in TLS after Bleichenbacher '98; instead, implementations just incorporated increasingly hacky workarounds. The PGP post upthread details the problems with the MDC, and the compounding implementation flaw in GPG that released unauthenticated plaintext to callers.

That MDC-era PGP remains the global standard, and that GPG continues to release unauthenticated plaintext to callers, just calls out further the impossibly compromised position PGP-based cryptosystems are in. You can try to do things like Sequoia that modernize PGP, but nobody in the installed base will be compatible with you, and the most popular and important "driver" of the protocol (again, GPG) is disinterested in mitigating the flaws of legacy PGP.

You can choose not to call GPG the PGP reference implementation, and there's no formal declaration anywhere saying that, but, it obviously is.

Re: Towards Sequoia OpenPGP v1.0

#54

Post by Leace »

qqii wrote: post #45
Leace wrote: post #26

Earlier quoted context omitted.

To be honest even PGP signing has some issues: it's not clear what does it mean to sign a commit and there is plenty of misuse of that (see [0], `git push --signed` solves some of these issues). Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1]. [0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repositor... [1]: https://people.kernel.org/monsieuricon/…

I now see how my original wording is confusing. I'm using git not as the specific case here (albeit interesting) but as an example. From my understanding keybase attempts to solve some of the more questions in your first link, simply 'r/commit/post/g'. For example: > He certainly knows his own posts, but how should others know that this “Linus Torvalds” guy who has been posting and commenting on posts is actually Lin…

Yeah... I guess a little bit it does. Keybase offers an alternative to Web of Trust that kernel.org itself uses (https://www.kernel.org/doc/wot/). Keybase solution is having multiple social-proofs instead of the Web of Trust. Sadly this is unnecessarily centralized but I've seen approaches to implement Keybase-like social proofs systems in pure OpenPGP: https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs

Re: Towards Sequoia OpenPGP v1.0

#55

Post by forgotmypw16 »

qqii wrote: post #44
forgotmypw16 wrote: post #18

Earlier quoted context omitted.

I'm using OpenPGP.js for drop-in decentralized client-side authentication for my web-based message board. This has several benefits, which includes giving technically-savvy users to do their own key generation and message signing using whatever tools they prefer, using one of the most widely used encryption/signing standards in existence. Meanwhile, non-technical users can create a new profile with literally one clic…

That sounds really interesting, would you be willing to share a link to the message board so I can see what your account creation process looks like? The other most common place I've seen PGP used as an account identifier are in darknet markets, where users are warned to use a GPG binary from a trusted source and against whatever serverside system that was built for ease of UX. Related to the issue that swiley mentio…

http://hike.qdb.us/profile.html

js required for key generation

Re: Towards Sequoia OpenPGP v1.0

#56

Post by upofadown »

tptacek wrote: post #53
upofadown wrote: post #51

Earlier quoted context omitted.

>...a failure both of the PGP protocol ... No. There were some changes in the actual protocol document that came out of EFAIL but no actual changes to the protocol other than a depreciation that was happening anyway. >...and of GPG, ... This also seems to be false. GPG didn't have to change anything as the result of EFAIL... >...its reference implementation. Also false. OpenPGP does not have a reference implementatio…

There were no changes in TLS after Bleichenbacher '98; instead, implementations just incorporated increasingly hacky workarounds. The PGP post upthread details the problems with the MDC, and the compounding implementation flaw in GPG that released unauthenticated plaintext to callers. That MDC-era PGP remains the global standard, and that GPG continues to release unauthenticated plaintext to callers, just calls out f…

It is odd you bring up MDC in the context of EFAIL as the EFAIL researchers were unable to come up with an exploit that MDC did not detect. Even if you feel that GPG should of anticipated EFAIL that means that OpenPGP as a protocol was secure against EFAIL.

It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You might not like MDC but you have to admit that EFAIL is not an example of any sort of a weakness in MDC.

Re: Towards Sequoia OpenPGP v1.0

#57

Post by tptacek »

upofadown wrote: post #56
tptacek wrote: post #53

Earlier quoted context omitted.

There were no changes in TLS after Bleichenbacher '98; instead, implementations just incorporated increasingly hacky workarounds. The PGP post upthread details the problems with the MDC, and the compounding implementation flaw in GPG that released unauthenticated plaintext to callers. That MDC-era PGP remains the global standard, and that GPG continues to release unauthenticated plaintext to callers, just calls out f…

It is odd you bring up MDC in the context of EFAIL as the EFAIL researchers were unable to come up with an exploit that MDC did not detect. Even if you feel that GPG should of anticipated EFAIL that means that OpenPGP as a protocol was secure against EFAIL. It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You might not like MDC but you have to admit that EFAIL is not an example of any sort of a…

I feel like we're not reading the same paper. The EFail paper I'm reading has a prominent chart showing which implementations it was possible to break the MDC in, and a section detailing how the MDC can be straightforwardly stripped off messages.

I note that you didn't respond to the rest of my comment.

Re: Towards Sequoia OpenPGP v1.0

#58

Post by upofadown »

tptacek wrote: post #57
upofadown wrote: post #56

Earlier quoted context omitted.

It is odd you bring up MDC in the context of EFAIL as the EFAIL researchers were unable to come up with an exploit that MDC did not detect. Even if you feel that GPG should of anticipated EFAIL that means that OpenPGP as a protocol was secure against EFAIL. It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You might not like MDC but you have to admit that EFAIL is not an example of any sort of a…

I feel like we're not reading the same paper. The EFail paper I'm reading has a prominent chart showing which implementations it was possible to break the MDC in, and a section detailing how the MDC can be straightforwardly stripped off messages. I note that you didn't respond to the rest of my comment.

Yeah, the paper did not claim that the MDC was in any sense "stripped off messages". They instead claimed that the mail clients ignored the MDC error.

>I note that you didn't respond to the rest of my comment.

The TLS stuff? We are just quibbling here. You have an irrational hate of things called PGP. Nothing I can say is going to change that.

Added: You are the one that brought up the MDC stuff but that really is beside the point. The problem here is with the leakage that HTML emails allow. EFAIL would still have nothing to do with PGP even if MDC did not exist.

Re: Towards Sequoia OpenPGP v1.0

#59

Post by GTP »

forgotmypw16 wrote: post #52
GTP wrote: post #43

Earlier quoted context omitted.

I'm not understanding how this works, then. Are you using the user's private key to somehow derive temporary device keys?

Generate a PGP key using in-browser JS. Use that key submitted posts. Then, later, sign either the file hashes or the public key itself using actual secure PGP. This is optional. I'm not claiming any level of security, this is all mostly UI prototyping.

Sorry, what do you mean by "Use that key submitted posts"?

Re: Towards Sequoia OpenPGP v1.0

#60

Post by qqii »

Leace wrote: post #54
qqii wrote: post #45

Earlier quoted context omitted.

I now see how my original wording is confusing. I'm using git not as the specific case here (albeit interesting) but as an example. From my understanding keybase attempts to solve some of the more questions in your first link, simply 'r/commit/post/g'. For example: > He certainly knows his own posts, but how should others know that this “Linus Torvalds” guy who has been posting and commenting on posts is actually Lin…

Yeah... I guess a little bit it does. Keybase offers an alternative to Web of Trust that kernel.org itself uses ( https://www.kernel.org/doc/wot/ ). Keybase solution is having multiple social-proofs instead of the Web of Trust. Sadly this is unnecessarily centralized but I've seen approaches to implement Keybase-like social proofs systems in pure OpenPGP: https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs

Ooh, I've not seen wiktor-k/openpgp-proofs before. Too bad it doesn't have more adoption, as I like it's solution to keybase's centralization.

Sadly neither project has an elegant solution to private accounts or services. IRC usernames and Signal are examples of the second. For private accounts, both solutions need specific tool integration, cooperation between services, or more manual interaction by the user. Ideally, a new internet standard would be created and adopted, but I really don't see that happening.

As someone who's put thought into this, I'm wondering what your thoughts on this are?

Post reply on HN