I have not. I had discussed a theoretical len(CT) == len(key) system with a friend for about 30 mins as a thought experiment, but we immediately poked a number of holes in it -- not the least of which being that we couldn't say anything about the security of the system on which it was deployed. Other questions: what to do with the key material files (their remnants would no doubt be left intact in NAND by opaque eMMC and SD controller implementations - and if not, some signal processing on the charge of the cells themselves combined with the regularity of whatever language was being used would give it up anyway - encrypting the key material might solve this to a degree). Also: where to get quality key material in the first place, and how to exchange it (NFC was discussed). I'll certainly take Claude Shannon's word on the security :)
1. Security of the system: I'm thinking about this lately: below in this thread I mentioned a setup involving an airgapped non-intel (eg. Rpi) computer that communicates ascii in morse code. This machine would hold the keys and encrypt / decrypt.
2. What to do with the files? You'd need to keep them as long as you need to use them. In my scenario it would be on an SD card in the raspberry pi. Afterwards.. there are many creative ways to destroy them :) i think an advantage of SD over HDDs is they are small enough to reasonably melt.
3. Key exchange: exchange the key on physical media, in person. Ensure the key does not come into contact with a networked computer (ask your friend nicely) and keep it away from any untrusted USB devices.
4. Quality key material: Hardware random number generator (also done on an airgapped etc machine).
I think I've covered everything, the only thing that crypto people on IRC could really complain about (it seems they really don't like OTP?) was integrity: an attacker could modify the message if they guessed parts of it.
I'm still figuring out how that would work (they assumed it would be used for a standard protocol with something like "From: andai@andai.tv" at the start of every message).
Now I'm just trying to make it so that anyone could set this up, which is turning out to be the trickiest step.
For the simplest form of encryption there sure aren't a lot of implementations out there...
In theory, a reasonable hash or CRC _inside_ the OTP stream would prevent tampering.
TEMPEST and DPA are other things I didn't consider in our thought experiment, but if I really wanted to be thorough, I would have. (I suspect there's very little signal for either in the OTP scheme).
I think the key exchange (sneakernet) is what makes the OTP approach unwieldy. If the source of randomness is good, and keys are not reused, in theory, it's the highest quality system out there.
I am thinking about a system for transmitting keys through the mail.
A microSD card is small enough to conceal inside of something else. I'm thinking of some kind of packaging where you could easily tell if it has been opened, and it would be impossible to re-seal perfectly.
It does not matter if the key is intercepted, as long as the recipient knows this, and does not use the key.
--
As far as TEMPEST goes, I think at the point the adversary is physically near you, you've got bigger things than encryption to worry about.
You could wrap the raspberry pi's case in aluminium foil. I'm not sure if the usb power cable leaks any signals: wrap it too for good measure ;)
