[Cryptography] Brainstorming for encrypted text messaging ideas...with a twist (Ray Dillinger)

[Arnold Reinhold]

On Fri, 23 Jun 2017 09:08 Ray Dillinger wrote:

> On 06/22/2017 03:52 AM, Arnold Reinhold wrote:
> 
>> ..... The front side had 100 sets of complete mono-spaced, ordered alphabets (ABCDEFGHIJKLMNOPQRSTUVWXYZ). The back had 100 randomly permuted alphabets, one behind each ordered alphabet on the front.... To encode with such a sheet, one placed it on a sheet of carbon paper with the carbon side up. The user circles  one letter of plain text in each alphabet. After the letters in the message were circled, one flipped the page over and read off the ciphertext from the randomized alphabets. 
>> 
>> A naive way to use the ORION system would be to follow the encoding procedure above and then take a picture of the reverse side and send it to the recipient.... The problem, of course, it that the position of the circled letter in each line of the ciphertext side reveals the plaintext letter.  I propose to overcome this as follows. Instead of ordered alphabets on the front side, have randomly scrambled alphabets. ...
> 
> I don't understand why to not just use the original format for the Orion
> sheets. One places the carbon paper directly on the desk, carbon side
> up.  Then the Orion sheet, with the ordered alphabets down, upon the
> carbon.  Then you go down (or across) the sheet, circling the letters of
> the plaintext in the permuted alphabets.
> 
> Turn the sheet over and what is now visible is the ordered alphabets,
> with apparently-random letters circled in carbon impression.  If the
> plaintext side is in fact not visible through the paper, then a pic of
> this sheet can be sent directly.  If the carbon paper is dusty on the
> non-carbon side, or your stylus leaves an impression on the wood and a
> "side channel" is made on the surface of your desk, the side channel
> only reveals the ciphertext again.

You are correct, I am just using ORION backwards. According to Boak, NSA abandoned ORION due to the difficulty of getting front and back in alinement, I was trying to avoid this problem by not printing the other side, but I have since done a test on an Inexpensive B/W laser printer, a Brother HL2240D, and it seems to have enough repeatability to make two sided ORION sheets, at least at 12 point type. 

Such a printer connected to a computer with no or little writable persistent storage, such as an old laptop sans hard drive that boots from a live CD-Rom should be able to print ORION sheets with full security, assuming a good source of random bits. (and, no, I don't want to restart that discussion).  The only need for persistent memory from batch to batch would be giving each set of sheets a unique edition ID. This could be done by having a paper list of IDs and entering one manually at the start of each batch's production. 

A Raspberry Pi has too much writable storage to be ideal for pad generation. Arduino’s don’t seem suited for driving a laser printer. 

> 
> Ultimately the encryption effort is no easier (Alice still has to find
> the letters in a randomly-permuted alphabet) but there seems to be no
> cryptographic logic requiring permuted alphabets on both sides.  The
> location of the ciphertext letter in a non-permuted alphabet reveals
> nothing about the plaintext letter.

Since encryption and decryption are symmetrical there is no loss of security, only loss of some, but not all, of ORION's convenience. You do have to find letters in scrambled alphabets, but you do not have to perform mod 26 arithmetic. I tried encrypting a short piece of text backwards using a sample of a related system called MEDEA (https://commons.wikimedia.org/wiki/File:NSA_MEDEA_one_time_pad.tiff). It took a bit under 4 seconds per character. I think it would go faster with crisper text.  In exchange, the ciphertext side of the sheet is safe to photograph (assuming no detectable bleed through from the scrambled alphabet side). It also means that used carbon paper is harmless and can be safely reused. Back when Boak was lecturing NSA recruits, carbon paper was cheap and plentiful in every supply cabinet. It's far less common today. Staples sell a package of 100 sheets for $20. 

> 
> As to trusting that the printing on the plaintext side is not in fact
> visible through the paper, one *could* worry about the paper and the
> optics and the light and the cameras.  I would prefer to unfold the
> paper at the center crease, tear along the perforated line, and use it
> to make the water in a blender just a bit less clear than it was before.

The bleed through issue could be addressed in a number of other ways, including using paper of at least a minimum weight and using grey printing for the scrambled alphabets.  Placing the sheet to be photographed on a dark backing when photographing the ciphertext, perhaps the carbon paper itself, should help. 

There was a discussion here a while back about dots in color copies being used to trace the machine used for the printing. To avoid such a technique leaking sensitive data, the unscrambled alphabet side could be printed separately in quantity before the rng is initialized to produce the scrambled alphabets. After printing scrambled alphabets on the other side of the unscrambled alphabet sheets, the printer's memory could be flushed by printing some number of not-to-be-used scrambled sheets that are then discarded. Ideally the computer and printer would locked up and never used for another purpose. Laser printers are cheap. 

One use case for photo-transmitted backwards ORION, without the image processing I originally proposed, might be someone in the field sending reports back to a headquarters, where someone could then do the more tedious decoding manually. Of course ORION sheets produced as above could be used in their original way and the ciphertext typed into a text message. 

Software for producing ORION style pads might be a useful addition to security-oriented distros.

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170629/50abcfc2/attachment.html>