331–340 of 350 posts
Earlier quoted context omitted.
Missing the point a little bit on 4. 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.
>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
Who here is using keybase to manage your public key being distributed? It seems like a great idea since your key is tied to your online identity
That said, I have about 25 invitations. Anyone want one?
Edit: Not true. I used my keys once to sign a GitHub release for a novelty project nobody uses.
Earlier quoted context omitted.
> Giving the government total, automated access to your communications 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 confir…
You're correct, I was distracted by some posts in this chain that seemed to be talking about using the key for encryption, not identification. 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…
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.
Earlier quoted context omitted.
> How do you distribute the one time pad in the first place? 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 conn…
I suggest implementing version 0.1 as either a frontend to GPG with key on an existing smartcard (Yubikey or similar), or at least something that uses the existing OpenPGP standard for encryption. That way you don't have to worry about doing the cryptography from scratch and can focus on the UI side (which is hard enough on its own) and the fingerprint exchange (which is what your "extra port" needs to be). You don't…
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.
Earlier quoted context omitted.
> How do you distribute the one time pad in the first place? 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 conn…
I suggest implementing version 0.1 as either a frontend to GPG with key on an existing smartcard (Yubikey or similar), or at least something that uses the existing OpenPGP standard for encryption. That way you don't have to worry about doing the cryptography from scratch and can focus on the UI side (which is hard enough on its own) and the fingerprint exchange (which is what your "extra port" needs to be). You don't…
Earlier quoted context omitted.
Private key required in the browser is bad. However if we had a system where those people that want or care can key their keys offline (or on a Smartcard) while those that don't want. Protonmail with SRP and 2FA where a attack has to pretty tricky stuff but you still get a e2e system is far better then what we have now. Its a far more involved attack to just look at your old emails, and its easier to detect. We will…
> Protonmail with SRP and 2FA where a attack has to pretty tricky stuff but you still get a e2e system is far better then what we have now. Its a far more involved attack to just look at your old emails, and its easier to detect. Can you explain how this is better than Google End-to-End? (Which isn't completed, I know.) Or even how it's worth implementing over regular webmail in the first place? Extensions are obviou…
The main benefit seems to be that to read your messages code has to be send to your browser. That is much easier to detect compared to compromise of the server now.
Plus it would have network effects that would benefit normal users.
In theory you could have clients with good guis and all that, these however barly exist and people simply want to use the web for this sort of stuff.
If your answer to solving a issue that billions of people deal with, then "Don't" is just not the solution expet maybe if there is a feature complete replacement.
Earlier quoted context omitted.
I have to partially disagree with that. 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 n…
> Just get the national government to distribute RSA USB keys to every citizen. 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-c…
Which country?
Earlier quoted context omitted.
I have to partially disagree with that. 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 n…
Guys. It doesn't have to be state controlled okay? It can be a SV startup if you prefer :D 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.
After all that, he was only getting two encrypted emails a year! Damn. That's crazy.
This has been my experience. The only "good" experience I've had with encrypted messages through email was a back and forth exchange I had with a fellow Keybase user where I manually copy and pasted blocks of encrypted text into/out of their web interface.