I don't think the "WoT" is conceptually flawed, and frankly, the argument that "people of average intelligence" can't grasp the concept comes from a very high horse and is also untrue. It's simply that any and all software for PGP utterly fails in the UX and functionality department when it comes to key management.

Web of Trust implies such a glaringly obvious visual metaphor that I am truly in awe that not a single program works that way.

Tabulations of keys are not a WoT, period.

I don't verify keys one-by-one, that's bullshit. I get one good key that's part of a WoT, and then go from there, and can easily see from the web structure that other keys are good and what their relations are. None of that is accomplished by any PGP frontend.

Instead I get stupid and unhelpful error messages ("no key available" - I just downloaded it!) and some of the most terrible crypto UI I've seen ("How much do you trust this key? [ ] Not at all [ ] A bit [ ] Fully [ ] Totally" - w-t-f).

A technical criticism of PGP/GPG is of course also possible. The whole thing is a museum of early 1990s crypto, with default ciphers like CAST5 and messages not being authenticated - and even if the message is authenticated most parts of the PGP protocol are not, meaning that you got that big bunch of C code maintained by that one German guy over there that parses unauthenticated bytes that you shipped through half the internet with a big neon-red sticker on it saying "I'M PGP PLEASE TAMPER WITH ME".

PGP needs to be as simple as the SSL Lock in a browser if there is to ever be any hope of widespread adoption. There needs to be a single system of trusted PGP universal key servers that allow the details of key generation/management to be hidden from the user, just like SSL is with the web browser.

We'd still be using HTTP if SSL was as complex as PGP. Same ssh replacing telnet. E-mail's lack of progress on this front is primarily a UX issue, and until it's solved PGP will remain a tool for the select few.

First email is "hey we're interested in blah..." and is sent in the clear. Then have the message window change color as subsequent emails get the protocol more secured.

Yet the world insists on using red/green as bad/good indicators. Drives me nuts.

(There's a 33% chance that exactly one of them is: 0.1 × 0.9⁴ × ⁵C₁).

Oh, I see. Assuming probability that a man is not colorblind is 0.9, then you found the probability of none of them being colorblind and subtracted that amount from 1 to find the other side.

For anyone reading this that was bothered by my use of a specific gender, it's because colorblindness occurrence is significantly higher in men than women.

    e^-0.5*sum((i)->(0.5^i/factorial(i)), 1:5) = ~39%

Why? This is basic statistics (% of population).

The Poisson distribution is what you use when the effective number of chances is "large". The Poisson distribution is effectively a special case of the binomial distribution, where the number of chances is infinity, the probability per chance is infinitesimal, and the product of the two is the expected number of events.

People who can't distinguish vivid reds/greens are much rarer. (If 10% of men couldn't separate red from green at the stoplight, we'd have noticed a long time ago.)

I agree we should include everyone, of course, which is why there should also be patterns, shapes, and sound to assist, I'm just saying color coding is not some collossal mistake.

(Also, your math is off if you're assuming a 10% base rate. To have at least a 50% chance of 1 person in a group of men being color blind, you need 7 men. 1-(.9^7)= 52%.)

Well, it has to use something, and other people would be colorblind in other colors, plus some will be blind too.

In this case, one would expect there'd be some OS-wide color utility to alter colors to the ones the user can discern.

This is a great check, but I also recommend trying things just in greyscale as a simple test and installing something like Color Oracle [0]. Also, most of the problems can be solved by looking for an already existing solution, like swapping your heatmap colour scales for viridis [1].

The most important thing is recognising that these kinds of issues exist and pro-actively looking for good current solutions (the same applies for things like trying to ensure your site works well with screen readers).

I'd love to hear of more tools or other things that can help if people have suggestions!

0 http://colororacle.org/

1 https://cran.r-project.org/web/packages/viridis/vignettes/in...

When sending or receiving email from other organizations, your mail server will communicate over TLS as well. Virtually all ISPs support TLS-protected SMTP today, and if you run your own server you can set it up easily enough. Google's Safer Email Transparency Report publishes statistics about the percent of encrypted email between Gmail and other top email ISPs [1]. TLS wasn't always widely supported in the past -- just as with web servers -- but any modern installation today will support TLS.

Modern email installations and usage are secure against passive surveillance as well as HTTPS. Where email is still weak is in its usage of opportunistic TLS (still common if not the default). An adversary capable of conducting a man-in-the-middle attack can force connections to fall back to plaintext, or can present a bogus self-signed certificate since many servers and clients do not expect a path-validated certificate.

There are defenses against those attacks, though. You can configure your SMTP server to require TLS, and to accept only path-validated TLS certificates from trusted certificate authorities. This will prevent an adversary from forcing your traffic to plaintext, and will prevent them from substituting a bogus self-signed certificate. With these protections in place, one can achieve a fairly good measure of security with basic email.

This is not to say that email is suitable in all circumstances. For high sensitivity use-cases one should consider attacks on infrastructure like the mail server: as we saw in this year's political campaigns, mail servers can be a trove of confidential information. One benefit of the GPG approach is that the mail server does not need to be trusted with the confidentiality of the communication, and so cannot compromise it.

[1] https://www.google.com/transparencyreport/saferemail/ The systems that show up as plaintext in this report are largely older commercial bulk email sending systems; all consumer-oriented ISPs adopted TLS a while back.

Maybe Let's Encrypt will change TLS adoption but I doubt it. It would need Google/Hotmail/Yahoo to increase the spam score for non-encrypted mail. But it's still way too complicated.

This only works if you're also forcing DNSSEC: otherwise, the attacker can substitute their own MX in your DNS responses.

Something like the level of confidentiality feature in (soon to be) caliopen[1]:

>> What is behind the idea of confidentiality level?

In Caliopen, every element has its own "confidentiality level" which tells the user what is the security level for any contact or message or conversation...

Each terminal declared by the user is graded according to its use (e.g. strictly personal, at home or as a public access within the enterprise), its type (a phone is necessarily less secure than a desktop PC, as it is much easier to loose). When used for the first time, a non declared terminal receives a note of zero.

Incoming messages are rated whether they are or not encrypted, and also according to the type of encryption key. The type of transport (secured or not) influences the rating as well as confidentiality level associated to the related contact if it is known. The algorithm that rates a conversation is more complex, but takes into account all described elements.

For a user's contact, the confidentiality level is equal to the global confidentiality level of this contact's account: this global confidentiality level is the only public element of a CaliOpen account.

Finally, every CaliOpen instance should eventually geWhat is behind the idea of confidentiality level? <<

[1]: https://caliopen.org/

I disagree. I have written email encryption software, and I find WoT complicated.

In light of this recent article on HN https://news.ycombinator.com/item?id=13111768 I suggest you re-evaluate the level of ability of the average user.

[]Distrust []Trust only this key []Trust this key to automatically trust other keys []This is my key

Obviously I dont know what all the levels exactly mean. but as far as I can tell, these are the levels of "web of trust", where for it to truly be a web, #3 should be the default.

I either dont trust someone, I trust someone to represent themselves, I trust someone's to vouch for of others, or I am that someone.

Calling PGP an utter failure is an understatement. Just like calling a cat a small tiger.

PGP is possibly the WORST experience in usability for any well known software that ever lived.

This thing should be taught in courses for decades to come as how to fail a product by 1) having no UI 2) no integrations with anything 3) zero usability 4) not even trying to give a fuck about normal users 5) in fact, not even trying to make it possible to use for advanced users.

---

You want signed email & identities. It's simple.

Just get the national government to distribute RSA USB keys to every citizen. Then they can use them on public government websites (taxes & jobs stuff) to confirm poeple's identities, just plug in the key. Quick and simple. (And that's not incompatible with ALSO asking for a password that was send in a different paper letter. 2FA-style.).

Then later, citizens can sign the emails they send to everyone with gmail/hotmail because they'll add the feature to recognize the national USB identity key, now that there are X millions people using it.

And to answer you, though I don't speak for the person you were relying to: the U.S. government isn't even in my threat model. If the Eye of Sauron points my way, I lose. And so, given that as a prior, a universally trustable third party is not a bad idea. The implementation might totally suck (and I think it's a better practice to have a wide set of vendors and making the acquisition of such a key subsidized, rather than directly provided, by the .gov), but the central point of trust doesn't, and it isn't inherently a problem for it to be state-operated.

""" If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they're going to use a drone to replace your cellphone with a piece of uranium that's shaped like a cellphone, and when you die of tumors filled with tumors, they're going to hold a press conference and say "It wasn't us" as they wear t-shirts that say "IT WAS DEFINITELY US," and then they're going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. """

A universally trustable third party key provider might not be a bad idea in itself, but a national government - any national government, I was not specifically referring to the US government - seems about as non-trustworthy as any third party gets. To my way of thinking, the whole point of cryptography is to allow the weak to protect themselves from the powerful, and giving the organization which is at least nominally the most powerful agent operating in one's area the opportunity to poison your crypto before you even begin seems... counterproductive.

Hello no. Absolutely not.

We're talking here about a state distributing USB keyz with a certificate to each citizen. The certificate is 'vouched' by the CA, it confirms the name of the citizen and it can be used to sign stuff thanks to private key cryptography.

One usage could be to access public websites, and use that USB key to log in and confirm your identity.

So the primary threat would be impersonation by the trusted party, which would erode the trust pretty quickly. I'm still a bit wary of this approach - do you think we'd manage to keep the keys from also being used for message encryption?

Where I live, there's actually a system somewhat like this in place - banks etc. can provide identity verification to websites upon request. You log in to the bank's system with your account and one-time pad they provide, and the bank tells you what information it will pass on to the requester. It seems pretty decent, and might actually be better than the USB key approach.

Now, that doesn't mean that we have to encrypt stuff. It could be used for the authentication/identification only if that's all one wants to do.

> It seems pretty decent, and might actually be better than the USB key approach.

Same thing. Look at RSA SecurID keys, they do certificate + OTP generators. I've had those at a previous organization, it was well integrated and nice to use.

The certificates provide the identity. A private key or an OTP allows for authentication.

There are multiple ways to handle the identity and the authentication with 2 factors. Exactly what to distribute and who will distribute it is an implementation details.

I lived in a country that did exactly that. And it was a disaster. The keys were trivially easy to steal, even by accident (personal experience here), and you still have the same trust problem as before, except that with a central authority now you do not have as much control.

I have also used the electronic-signature-comes-with-your-ID-card thing, and it was a similar disaster, with dodgy drivers and half-arsed crypto implementations in common software. E.g., try using the same token in Firefox and Thunderbird (or anything else) at the same time.

PGP is fine. It's just that proper security is not easy. And the same applies in the physical world as much as in computing.

The implementation and the technology has some challenges to be executed. Just like everyone tech projects, that doesn't have GooMicroZon people. Nothing special ^^

So distribute keys on smart cards that don't allow you to export the key. This is what Estonia does, and - concerns about their election infosec aside - it seems to work pretty well.

That's what I covered in the second paragraph. :-)

The thing is, both those implementations were a disaster from either a technological or a security point of view. We're not even getting into whether a central source of trust is a good idea or not (you will look at the state of HTTPS and make up your own mind on that). So, to repeat, proper security is hard.

Which country?

If you don't mind me asking, what country?

The second half--the federal government as centralized national PKI, generating everyone's private keys for them--is hilariously terrible.

I can almost hear Moxie, Matt Green, Trevor Perrin, and every infosec researcher and crypto engineer and privacy advocate facepalming in unison.

The government is just an example because they already handle ID for everyone, and they need it to provide their services. It makes sense for them to go digital at some point and to guarantee the ID.

I didn't know that Americans were so anti-American ^^

We are a majorly paranoid society, for no particular good specific reason that I can see.

Shipping a national backdoor is an entirely different topic. Please focus on the use case at hands.

I guess that makes sense. People in the UK don't have any "national ID card". Must be a culture thing.

I guess that makes sense. That's why I have to go through fucking stupid private background check agencies for everything in the UK.

That "U.S. Government" collecting, indexing and analyzing all data of any citizen must be an entirely different entity from the "United States Government" after all.

Every single corporation here and even freelance service workers are required by law to have a key/certificate pair to be able to do file taxes.

Pretty much every single commercial transaction is signed with a certificate.

It is not yet required for every individual citizen to have one, but everything points to that happening at some time in the future.

Estonia does provide S/MIME certificates for every citizen, although I've been told that they're not particularly heavily used.

Between Estonia and the DoD, there's a few million users of S/MIME. Whereas PGP has a few tens of thousands of users. It's clear which product won out in the marketplace.

Which experts? And what are those fundamental flaws?

Honestly, this made me laugh.

But it also makes me think. GPG and PGP are ancient pieces of somehow working code that probably should not be allowed to operate any significant parts of human communication.

IMO we should aim for a Crypto like Signal presents it; simple yet secure enough for most users.

It might be worthwhile to bring Signal (or atleast the idea) to other protocols like E-Mail.

I'm glad to see someone else thinking the same way as me on this! I got myself an idea for Yet Another Secure Messaging App a while back. After a little market research, I kinda decided, well, everything that I want to do can already be done by PGP, or Signal, or Whisper... except that where they are easy to use, they don't integrate with e-mail, and where the integrate with e-mail, they are not easy to use. So, there's still room for more diversity in the market of providing easy-to-use secure, verifiable messaging, especially without trying to replace e-mail wholesale like so many messaging platforms (secure and otherwise) do. And maybe I'll actually get around to building it someday.

Signal has managed to do the "How can we exchange keys while atleast one of us is always offline?" part. So a good and somewhat PFS key exchange should be possible too.

Integrating that seamlessly with email is gonna be hard and require a service to register emails or domains that support the new protocol. Otherwise you end up with the PGP situation.

One want people's mail to automagically encrypt when both have it. Automagically is the best security there is for Joe Average. On the big list of security problems you face for Jane Average, "Werks Automagically" is Point 1 written in golden ink by the pope himself in 72pt fontsize and "Secure against State Adversaries" is Point 2 written in silver by the pope's cat on the second page in 16pt fontsize.

One might also want to introduce a benefit, like disabling it for spammers by having some kind of verification (Phone Number or something?) and heavily police HTML formatting so that little Green Icon next the email means more than "this one spent 30 seconds to find a large prime pair" and more like "this email is probably safe to open, nobody will track you and nobody is going to sell you fake viagra".

People should want to use it, not have to use it to be secure or something.

But as you said, that all requires work and 99% of my time I personally like being unproductive, so I guess it'll never happen.

I like this idea a lot!

The average person already struggles to even use a computer and to accomplish tasks which seem very basic to us. [0]

I can't imagine them figuring out how to use PGP. The WoT is a complicated system to understand for even technically proficient users, let alone average ones.

[0] https://www.nngroup.com/articles/computer-skill-levels/

First of all, the WoT is based on belief networks. What is a belief? Is it based on a probability? Is it binary? Can we believe something negatively? Whatever it is, we know it is subjective and difficult to define quantitively.

Second of all, even when formally specifying a belief using a certain quantity, we need to calculate transitive beliefs (person A beliefs with certainty x the identity of person B, C and D, who each believe with certainty y the identity of person E and A). This requires doing some matrix inversions for which the whole matrix needs to be known. However, who do we trust to provide us with the matrix? If I can provide the matrix, I can also tamper by adding extra nodes, thus shifting trust towards nodes I control. We can provide the matrix in a distributed fashion, but how do we prove completeness?

Then there is a temporal aspect to WoT which is hard to tackle. I might have a belief now, but that does not entail I will belief it tomorrow. Without a continuous stream of events on a subject, the precision of my beliefs are always diminishing. However, the current WoT networks do not take this fully into account (or transitive beliefs for that matter).

Yeah, but it doesn't actually work. The fact that I know you (i.e., I'm willing to certify your identity) implies nothing about my trust in identities you certify. For all I know, you mint a new identity every second, and then use all those newly-minted identities to cross-sign one another's keys.

I don't think WoT or PGP are fundamentally flawed - but we need a lot of experimentation to make it work and for that we need good libs.

I think it's the key model that's fundamentally flawed rather than pgp itself, which I believe the author of the article is also asserting.

In cryptography, it is often explained that despite the fact a one-time pad is guaranteed-secure (given various conditions I'm eliding), it is not practical in the vast majority of cases because of a chicken-and-egg problem: How do you distribute the one time pad in the first place? If you do it insecurely, it's a waste of time. If you can do it "securely", why not just use that secure channel to send the message in the first place? OTPs can still be useful because you can establish a secure channel once for a limited duration of time and then use it to temporally shift your security into the future, but that's a relatively rare use case. (That is, the vast bulk of encryption is being used between people who may never have had a "secure" channel between them; think HTTPS here.)

Similarly, PGP's got this significant problem where given that you have the correct keys and that you know you can trust them, it secures your communication quite effectively. But the question is, how do we get to the point where you know that you have the correct keys and you can trust them? Well... that's a hard problem itself. Especially considered over time.

So alternate models must be pursued.

Like the author, I think the Keybase approach is a good idea. In fact I'd even suggest that the idea should be generalized away from "social media accounts" to just "potentially unreliable mechanism" in general. If I have 6 mechanisms for asserting identity on my key, each of which are 95% reliable over the course of a year, then from an absolutist security point of view, that key is still insecure... but assuming even modest independence between the unreliable mechanisms (assuming naive total independence is definitely incorrect, once one is hacked the others are certainly more likely, but neither is it the case that one hack guarantees all others can be hacked), it's still much more secure than nothing at all.

Something I've wanted to make for a while now, that should be possible to make with almost any cheap embedded microcontroller, is a hardware dongle that stores OTP pads. This would be a generic character device that could be integrated into existing chat programs.

* Each device has a hardware RNG, e.g. [1] or similar

* A port that allows two devices to connect. When connected, they each start generating random numbers, sending a copy to the other device. They both store the XOR of each device's random number as the pad.

* A USB interface accepts plaintext, the device generates the cyphertext, while enforcing deletion of the used portion of the pad. Decryption is handled with a similar interface, so the pads never leave the device.

* The device would provide to the host how much pad is remaining, to be used in the UI. Warnings should be provided when the pad is running low, etc.

The goal is to utilize existing knowledge and experience. Schneier (and others) recommend[2] that passwords be written down because people's understanding of physical security is better than their chances of memorizing enough entropy to actually make a usable password.

This isn't trying to solve the general WoT problem. Instead, it tries to solve a piece of it in a way that most people can understand. Connect devices when you meet in person, and you gain a certain amount of secure chat. Refill by meeting in person again.

It would be easy to extend this idea to provide other features (e.g. generating pubkeys), but since the goal is a simple device that is easy to understand, avoiding feature creep is important, at least initially. Features like WoT will be easier to implement if there is existing infrastructure that can be exploited.

[1] http://holdenc.altervista.org/avalanche/

[2] https://www.schneier.com/blog/archives/2005/06/write_down_yo...

But if we go to all this trouble, we might as well use public key cryptography, it's even easier to use. Internally, the dongle will be quite complicated, with stuff like Curve-stuff, Xchacha-something and poly-whatnot. What the users needs to know is simple:

Once initialised, your Dongle can publish a public a "fingerprint" that is unique to it. To decrypt messages encrypted with this "fingerprint", you need your dongle. To sign messages according to this "fingerprint", you need your dongle. If you lose it, your "fingerprint" becomes unusable, no recourse. If it gets stolen, the thief will be able to impersonate you, unless you did the sensible thing and locked your dongle with a secure passphrase (think Diceware).

Now we engineers can figure out how to make that dongle easy to use and secure against any compromised computer it may be plugged in. (We don't want the dongle to become untrustworthy just because it got out of your sight during lunch).

That's exactly the kind of complexity I'm trying to avoid. I would get zero benefit from existing public key infrastructure, because this is a device that enables 1-to-1 communication only. It may be possible in the future to exploit such a device to authenticate GPG keys, but not in the initial version.

> cryptography from scratch

I'm not doing much crypto other than generating random bits (hardware RNG with whitening). One of the reasons for doing this in an embedded device is to keep everything important isolated on the device (data diodes are useful) where the "one use only" rule can be enforced. The computer-accessible attack surface would be extremely small; it's mainly just a USB (or whatever) character device you write plaintext to and read back the OTP'd cyphertext.

> fingerprint exchange

There is no exchange or fingerprints. The entire goal is to have a type of secure communication that is easy to understand, so it can't have complexity like handshakes to exchange stuff or key management. Even if its hidden behind a UI, those features add complexity that affects how you use it.

> gets critical mass

Again, the goal is to not need critical mass. You only need that if you're trying to solve the general WoT problem. I'm only trying to provide communication between a pair of devices that will have to meet in person for synchronization.

> useful to more people

I'm assuming that people that know about GPG can already handle setting up their own secure communication. What I want to try is something that provides some features that everyone can understand. Trying to solve the entire problem at once has always made tools that were too complicated to understand if you have never of crypto. You might consider the device I've described as a kind of "training wheels" for the idea of using crypto.

> producing something

I'm not producing anything right now; this isn't a product of business plan. If I ever find the time and money to work on this project, it will just be a handful of hand soldered RNGs on Arduino boards or similar.

It's only complexity for the implementation, not for the user.

> I would get zero benefit from existing public key infrastructure, because this is a device that enables 1-to-1 communication only.

You'd get to reduce the storage requirements massively and make the devices much more reusable, because you wouldn't have to do exchanges and store the results.

> There is no exchange or fingerprints. The entire goal is to have a type of secure communication that is easy to understand, so it can't have complexity like handshakes to exchange stuff or key management. Even if its hidden behind a UI, those features add complexity that affects how you use it.

The UX is "plug these two devices into each other via some special custom port" either way, no?

> The computer-accessible attack surface would be extremely small; it's mainly just a USB (or whatever) character device you write plaintext to and read back the OTP'd cyphertext.

If the UI is a unix character device then your target audience is a subset of the people who already understand GPG.

> Trying to solve the entire problem at once has always made tools that were too complicated to understand if you have never of crypto. You might consider the device I've described as a kind of "training wheels" for the idea of using crypto.

Right, but part of the point of training wheels is you attach them to a regular bike, you don't use a completely different device. A specialized frontend that only uses a very small simple subset of GPG would be very helpful.

Minimizing complexity is also important when writing a security feature. The entire firmware shouldn't be very large (bugs/kLOC is constant(-ish)), and dependencies increase attack surface.

> reduce the storage requirements

I don't see that as being a huge problem, because flash memory is cheap and I should be able to generate pads very quickly. Remember that the only problem I'm trying to solve is secure chat (text). 1MB of pad is a lot of typing.

I do like the idea mentioned in another comment about using the shared random secret as a stream of symmetric keys, which would nicely reduce the rate of pad usage without adding any more complex semantics.

> If the UI is a unix character device

I'm describing it to you as a character device, because I assume you know approximately what that implies (serialized data stream, etc). The UI for the user, for now, would probably be a plugin for libpurple or something, if I ever get time to write it.

> a very small simple subset of GPG

I've been trying variations of that idea for over 20 years. Many people need a far more rudimentary education about the idea of using crypto. I want to teach the idea of applying security at each end of the conversation. I want to teach the habit of putting an envelop on communication, even when it's just to a friend. I want to teach taking some of the responsibility for your own security instead of relying on 3rd parties ("the cloud").

I've tried to teach very small subsets of GPG already. That didn't work, so I'm simplifying the scope into something that will hopefully be easier to understand.

The "minimal GPG wrapped up in a very simple UI" device that you're talking about would make a great device to graduate into.

In the general case yes, but GPG is probably or at least should be the most carefully audited codebase in the world.

> I do like the idea mentioned in another comment about using the shared random secret as a stream of symmetric keys, which would nicely reduce the rate of pad usage without adding any more complex semantics.

Right, at which point you already need a high-quality symmetric encryption implementation (and definitely need to worry about timing attacks and other side channels - quite possibly something you need already at the true-OTP stage). Such as the one in GPG.

> I've been trying variations of that idea for over 20 years. Many people need a far more rudimentary education about the idea of using crypto. I want to teach the idea of applying security at each end of the conversation. I want to teach the habit of putting an envelop on communication, even when it's just to a friend. I want to teach taking some of the responsibility for your own security instead of relying on 3rd parties ("the cloud").

All good things. I just struggle to believe that the amount of internal-only simplification you get out of making the device OTP-only is worth the cost of requiring storage, becoming text-only, having to have one device for each person you communicate with, having no way to send messages to people you haven't met, and avoiding compatibility with what is still the most widely deployed cryptosystem with any hope of being secure against government-level threats (and the only cryptosystem that we have the NSA on record as being unable to break). I can certainly believe that most of these things aren't worth exposing in the UI, but deliberately using a different standard for the implementation to ensure that you will never have the ability to add even one of those things should they actually prove desirable seems like a poor cost/benefit.

I'm fairly naive to this area, but wouldn't video chat initiated with public keys suffice? Then confirm identities and exchange secrets. To me this seems substantially equivalent to in-person key exchange for non-Three Letter Agency threat models. 20 years ago this wouldn't really have been feasible, but today it (mostly) is -- from a quick glance at the FAQ, Signal may even support something like this already.

(If your threat model includes "abduction and coercion", then aren't you kind of hosed even with previous in-person OTPs?)

For one, if the video chat is secure enough for an otp exchange, the otp isn't needed.

Secondly, if your video chat gets recorded, which may very well happen, you need to use ephemeral keys.

Thirdly, since the video chat is likely recorded, at least the meta information, the effective security of your otp degrades over time, as new breaks or speedup s are created for the video chat cipher.

I realized I probably should not have replied to the part about OTPs specifically. What I'm curious about is remote trust verification via secure video.

By "cracking the keys" a cryptographic break is not always required. It can also happen via disclosure, a weak implementation, problems with the protocol, etc. One can scan a list of recent vulnerabilities for this: session reuse, master secret reuse, session resumption, heartbleed, etc.

I would call these out in particular here, because secrets are being exchanged. If those inner secrets are used to protect (directly or indirectly) multiple messages, the key disclosure becomes more pronounced.

You are quite correct regarding quantum computing. QC is guaranteed to break elliptic curve, DH, or RSA for example. The determining factor is the number of q-bits.

What do you mean by remote trust verification via secure video. That sounds quite interesting. Do you mean facial recognition inside a channel assumed to be secure, as a secondary validation of an otherwise "pre-trusted" party?

By transmitting your OTP it is no stronger than the method used to protect it in transport, so if that transport method is secure enough to guarantee the security of the OTP, why not simply use that method for everything and forget about the OTP?

What I'm trying to understand is whether the (relatively new) feasibility of interactive video channels allows for building roughly the same level of trust as would be provided by in-person key exchange. I'm basing this on the understanding, possibly incorrect, that encryption with a public key allows for creating a secure communication channel, but not necessarily a trusted one. The hypothesis is that the capability to conduct interactive video provides a way to verify identity and establish trust at roughly the same level as would be provided by in-person exchange (again, assuming 1-1 trust, and excluding TLA threat models).

Example: Alice wants to video chat with Bob to exchange the secret key and verify identity. Mallory sets up a MITM attack, and gives her own public key to both Alice and Bob. Alice and Bob think they are securely talking with each other, but they are actually securely talking with Mal, who decrypts the video, watches it, then forwards it on to the other person.

This is why you can't have a secure communication channel without trust; you don't know if your secure communication is being intercepted, read, and then passed on.

Because you may not have any messages to send at the time of the secure exchange of OTPs. Do note that one time pads are (or at least were) commonly used in the military.

> But the question is, how do we get to the point where you know that you have the correct keys and you can trust them?

That is not a technological problem per se, but rather a social one. Imagine that when you exchange phone numbers (or Farcebook IDs, if you're into that) with your work colleagues, or friends, or fellow attendees at that developer meetup, you also exchanged public keys.

Mechanically, the interaction is at about the same level of complexity, and effectively, as has already been mentioned, the web of trust already exists (Farcebook, ChainedIn, and all the other bollocks).

If any of those decided to implement secure end-to-end comms using PGP and offered you the possibility of uploading your public key for dissemination to your "friends", PGP might become ubiquitous in a matter of weeks. At a smaller scale, German email provider GMX is doing exactly this, by the way.

It already has this to a small extent. You can sign other stuff like domain DNS entries or HTTP servers (by hosting a file).

Well you hand it over to the person you want to communicate with when you see them?

Obviously that doesn't work in many use cases, but in many other cases it does: many of the most important secrets are typically shared with people you already know and have met before, no?

The vast majority of encryption in the real world is between people who did not meet and exchange crypto info.

(Note this is specifically about one-time pads. While I agree the Web of Trust has failed, it is one effort to circumvent the problem.)

If even he says "write me an email in plaintext" then I'm not too hopeful for crypto in General.

But when you discuss the real secrets with a journalist or business partner in another country. Email communication with family members, business partners.

Potentially web traffic with your company's or bank's website, why not.

eg he was saying you can't share a key across multiple devices. Or if you do, you just increase your attack vector and your weakest link becomes the hotel wifi you plug into.

eg if your key does get compromised, now you have to rotate all your contacts, which if you distributed your key on a business card, is pretty friction-prone and encourages you to discount that weird activity that could have been a blip you saw on the hotel wifi.

The big one is if your key ever does get compromised, now all your past history becomes accessible. So he's saying there's some things that PGP is fundamentally bad at, and you need a new model, not just a band-aid UX fix.

> Finally, these days I think I care much more about forward secrecy, deniability and ephemerality than I do about iron clad trust. Are you sure you can protect that long-term key forever? Because when an attacker decides to target you and succeeds, it won't have access from that point forwards, but to all your past communications, too. And that's ever more relevant.

So what are the options here? You can have a GPG key protected by any mechanism you care to think of (passphrase, smartcard, ...). You can share it between devices or not as you see fit, subject to the same tradeoff that is always going to be involved in that decision. I can't see any way to do it better?

> eg if your key does get compromised, now you have to rotate all your contacts, which if you distributed your key on a business card, is pretty friction-prone and encourages you to discount that weird activity that could have been a blip you saw on the hotel wifi.

PGP actually has very good support for key rotation by using subkeys - you keep your master identity key offline/secure and that's what other people sign, but you use it only to sign subkeys with short expiry times. People don't use it, but that's a UX issue.

> The big one is if your key ever does get compromised, now all your past history becomes accessible. So he's saying there's some things that PGP is fundamentally bad at, and you need a new model, not just a band-aid UX fix.

True, but I think long-term signing is often what you want. There are different models that make sense for different communication scenarios certainly.

Things PGP can do:

- Hide the contents of a message. But not the fact of a message nor who it's to. And it's only as hidden as a key that your recipient has to keep secret indefinitely.

- Permanently be incriminating, since the message can be as easily opened a decade from now.

- Prove you're you. Which is great for incriminating you. Also the proof is only good if your secret key is still secret, which probably isn't the case if you've been arrested. At that point, it's good for convincing people it's you when it's really the FBI.

- Authenticate keys through a trust mechanism so sparsely populated that unless you're actually in a spy cell, the chances of having a valid trust path from A to B is astronomically small.

- Distribute keys through what is really only slightly more sophisticated than a world-writable Dropbox.

Far as a decade from now, that's probably all you need given the statute of limitations.

I'm not googling this type of query at work, but typically as more information about a crime becomes available to law enforcement, the statute of limitations is reset. So if you're buying something illicit and securing communications with PGP, and the SOL is 5 years, if LE doesn't get the contents of that communication for 4 years, they still have 5 years to decide what to do with it.

All SOL means is that LE can't sit on incriminating information about you indefinitely and pursue charges decades in the future for minor crimes.

2) Key rotation solves this, but you lose the ability to read old messages yourself. If you don't have the keys anymore you can't view the message.

3) This isn't unique to PGP? Or do you have an alternative? Because plaintext is infinitely less secure in this regard.

4) Depends how you determine trust of a user. In an ideal world you'd be correct. But I trust the person I've known for nearly 6 years is them when I signed their key, though we've never met IRL. Very possible it isn't them but is also astronomically slim of a chance.

Key rotation makes the WoT even more complicated and less trustworthy. That's a big problem.

Proving you're you is great if you're, say, Canonical distributing package updates to Ubuntu, where the adversary is malware distributors.

But where your adversary is eg: the FBI, then it promotes a false sense of assurance, because it's actually really easy to spoof someone if you can arrest them and force them to give the key password.

Country dependent [0]. Not enough evidence one way or the other for FBI coercing.

[0] https://en.wikipedia.org/wiki/Key_disclosure_law

So, best practice: publish your private signing key publically if you ever get arrested?

The Web of Trust is built on long term trust of objects that should be short term and plentiful and that does seem an inherent contradiction in terms. WoT "best practices" have always been that keys should never live that long (at most two to five years being an old received wisdom back when I was most actively exploring the WoT), but proper key signing involves lots of little contacts (or key signing "parties") that are slow to accumulate and should last a great deal of time, but are applied to a specific key.

Power Users can get some continuity between keys when rotating them by signing new keys with old ones before they expire, if they can manage that key that long and are prescient enough to build and sign a new key. (I know I lost continuity with my most trusted WoT key by not managing it well enough and I'm certainly not alone there; there is a great deal of churn in the WoT and lot of it is expired.)

So Power Users try for longer term keys with further risks and even larger key management issues and with those longer term keys they try to manage a coterie of smaller term keys exponentially increasing the number of key management issues.

Keybase seems to be the best bet at a trust model that distinguishes active keys from long term trust (social trust), and might be a good answer if they solve "average user" user experience.

Signal and WhatsApp and some of the other OTR-ish mobile apps with E2E encryption seem to have solved some of the "average user" user experience problems, but don't seem to have good long term trust models.

Somewhere in the soup maybe someone will solve more of the chicken-and-egg hurdles and evolve something that works for everyone.

yes, yes we do. All this stuff seems easy if you have the curiosity so spend hours and hours reading dry documentation about how it works. This is to say nothing of actually getting your hands on the tech and inevitably having problems that require more hours of forum searchs, IRC, and other time drains.

It's not that "regular" people are too stupid to do this, they just don't see the value proposition in it. Even when the privacy issue starts to negatively affect regular people (think Black Mirror "Nose Dive") many still won't be interested in the technology to do what I wrote about above.

I spent a bit of time in the crypto community and immediately I realized there is a human resources problem. the communities, for the most part, have no one that understands or care about how to dumb the UX down enough to make the value prop work for regular people.

Last time I tried to use PGP on Windows, the gpg4win setup application crashed repeatedly during installation, and I had to use a walkthrough with screenshots because I couldn't figure out how to sign messages in Thunderbird.

Forget deep conceptual usability issues; there are tons of major surface level usability issues.

Basically, if you can swap contacts via NFC then the pgp keys should go along with it.

It may have some theoretical weaknesses such as the exchange being MITMable if the users don't verify something on their screens, but I think having many more edges in the graph would make up for it since you might already have an expectation for that key through friends-of-friends paths.

IMO, the idea, the model, and implementation are flawed.

The idea that people care about a web of trust in general is bad. The model itself relies on the assumption that it's a popular piece of software that is used in the way it's intended. PGP itself is popular, but only for the fact that viable alternatives are thin. The software implementation is confusing to technical end users, and third party front ends are just as bad.

Well, the very question is kind of a type error: people don't know what a computer is in the first place. 1 in 4 can't use computer in any capacity, and 90% of the rest have zero knowledge of the underlying principles. They don't even know if they would care about a web of trust.

In the mean time, the powers that be are building us a network of universal spying. Oh well.

Why not both? PGP is definitely flawed with its lack of perfect forward secrecy.

Of course, you need to delete emails once sent and once read in order for PFS to be of much value. However, without PFS, there's really no such thing as a deleted email, just emails the FSB/NSA haven't yet rubber-hosed you for the keys yet.