[Cryptography] Brainstorming for encrypted text messaging ideas...with a twist

[Ray Dillinger]

On 06/17/2017 05:04 PM, Grant Schultz wrote:

>    It would work, but you'd want something less unwieldy than a
>    one-time pad. I think you would want some kind of purely mechanical
>    device, so that users could verify for themselves that it is
>    unhacked and unhackable.  All parts visible.
> 
> 
> Yes, the all-parts-visible is the important aspect.
>> And neither of these methods gets around the difficulty of typing random
>> characters into a smartphone.
> That's why I was aiming for a device that could show a line of text on a
> physical display (perhaps a stack of wheels of some sort), so that the
> ciphertext could just be photographed right off the device.


So....  This might actually be mechanically possible, if complex. I
imagine a device with a set of message wheels (20 alphabetic rotors?)
under a narrow window so you could read one row. Visible on the opposite
side through a different window but probably on the same axle, would be
a set of key rotors (another 20 alphabetic rotors?).  Each rotor would
be settable with a thumb wheel, and there'd be a winder and a counter on
one end.

Ideally, it is made so you can take it apart and permute all the wheels
on the axle for a longer-term shared key, but for individual messages,
it would use a 20-character session key and a 20-character IV.

Alice sets the session key on the key rotors on the back, sets the
message wheels to some random value(IV) in front, takes a pic and
transmits the pic to Bob.

Then she repeats:  wind forward until the counter has changed twice,
set a line of plaintext, wind backward until the counter changes,
take a pic of the ciphertext now on the message rotors, and send to Bob.

On the far end, Bob sets the session key and the IV value he
sees in the first pic, winds forward until the counter changes, sets the
ciphertext he sees in the second pic, winds forward again, and a line of
plaintext appears.  He then sets the ciphertext he sees in the third
pic, winds forward again until the counter changes, and the next line of
plaintext appears.  And so on.

If Alice & Bob have the patience and are paranoids, they could do a
forward-5/backward-3 encryption with the counter instead, or whatever
else.  But if that's necessary to the security of the cipher, the maker
should just make the device so the counter changes less often instead.

The device itself would implement an autokeying block cipher on
40-character blocks, with 20 characters of the previous block's
ciphertext used as a sort-of-CBC-mode. Both the key wheels and the
message wheels would change chaotically while winding, each move of the
key wheels depending on the previous state of the key wheels only, and
each move of the message wheels depending both on both the previous
state of the key wheels and the previous state of the message wheels.

The device would need to have a bidirectional property in that whatever
happened winding it one direction could be reversed by winding in the
other direction, so the state transitions are limited to a one-to-one
function.

I can sort of imagine an implementation of it with a bunch of
interlocking slidey bits that would remind a lot of people of a sort of
cylindrical rubik's cube.  But it would have, conservatively, at least
200 moving parts.  Making it cheap enough to sell or small enough to be
convenient would not be at all easy, and somebody who knows more about
group theory than I do would probably spot a flaw in the cipher.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170618/27bb9b85/attachment.sig>