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.
> That's exactly the kind of complexity I'm trying to avoid.
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.
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.