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.
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...