On Thu, Oct 03, 2013 at 02:34:50PM -0700, Malard Joel wrote:

Do you think that the code at  https://github.com/malardj/ slice,  that uses neither encryption nor a password, could help a community proof their communications from massive systemic eavesdropping by making the latter computationally impractical or financially unsustainable?  Do you think that a tool like that would be valuable if it existed? Would you think of some yourself that everyone could use?

I am unaffiliated with any institution but I would like to setup a contest for the best such algorithm or procedure that does not involve cryptography and that can be implemented by any group of ordinary citizens for the purpose of proofing their Internet communications of ASCII characters from systemic eavesdropping.

I need help setting up the rules of competition ( i never did this), finding judges (I am totally unqualified), finding (virtual) places where to announce and hold the competition. I would welcome your suggestion on how to make this contest more relevant to all. Can you help, or suggest where to look for help?

The code above is a quick example of the type of entries that I have in mind. It consists in a C++ program that inputs a character string, slices it  and shuffles those slices into a javascript program that displays the input when it is run. The method purports to hamper the work of automated keyword harvesters.  The available code does not  support html text but that capacity is not be hard to add.

With best regards,

Joel Malard, PhD Fremont, CA

I don't think this is the right list for this discussion, but how about:

- Pick a 128-bit random key K - Encrypt the message using key K with, say, AES-GCM or your favourite authenticated encryption mode to yield the ciphertext C (including tag) - randomize the last b bits of K to yield K', for some b, probably around 30, but could be anything from 0 to 40ish. - output K' concatenated with C

Notably, you don't output b. The receiver just runs a counter X up from 0 until C authenticates using the key (K' XOR X). b controls how long this will take, but the receiver doesn't know it. (There was a password-stretching algorithm like that in USENIX Security (I think it was) a little while ago; the adversary doesn't know how many iterations to wait before giving up / trying another password.) The high part of K acts like a salt.

It's kind of like the old Lotus Notes encryption, in that the NSA got to know the high part of the key, and just had to brute the low 40 bits, only now the receiver has to brute it as well. It's not technically encryption, as there's no shared or public key. But there's also no key management, of course.

- Ian