Welcome Guest [Log In] [Register]
Welcome to Crypto. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
Using a text to make an OTP
Topic Started: Feb 13 2014, 08:33 PM (402 Views)
fiziwig
Elite member
[ *  *  *  *  * ]
Project Gutenberg has thousands of books available online. Any one of them could be used to generate a one-time-pad type of keystream. Start with a text, say "Moby Dick". Squeeze out all the non-alphabetic characters, then encrypt the text using any polyalphabetic cipher method that will even out the letter frequencies.

It doesn't matter what method you use because you have no need to ever decipher the ciphered version of the text. It just needs to look like random letters.

Next, using some secret key number N, discard the first N characters of the text. What's left is your OTP.

If you recipient knows what text to use, what polyalphabetic cipher to apply, and what N to use, he can recreate your OTP You could also agree upon some kind of transposition of the OTP characters, or whatever else would make it more difficult for somebody else to work out a copy of your OTP.

Or you could take two texts, say "Alice in Wonderland" and "Peter Pan" and use one as the key to encipher the other, then transpose and encrypt with a Vig then discard the first N characters to make your OTP. Then the enemy has even more pieces of information to reproduce your OTP.

But the point is, you could pre-arrange with your recipient a way to build as many OTPs as you might need, as you need them, without having to exchange the actual OTPs.
Offline Profile Quote Post Goto Top
 
mok-kong shen
NSA worthy
[ *  *  *  *  *  * ]
Just like to mention that I had an article that apparently goes in the same direction: http://s13.zetaboards.com/Crypto/topic/6936496/1/
Offline Profile Quote Post Goto Top
 
fiziwig
Elite member
[ *  *  *  *  * ]
mok-kong shen
Feb 13 2014, 08:53 PM
Just like to mention that I had an article that apparently goes in the same direction: http://s13.zetaboards.com/Crypto/topic/6936496/1/
Thanks for that link. I must have missed that the first time around.

I like your idea of combining 5 characters to make one OTP character. I'm not sure if mon-alphabetic substitution is good enough to get uniform distribution, though. That's why I suggested using a poly-alphabetic technique like a Vig on the original text.

I also like your idea of combining three texts. If you used texts that are available online, and are likely to remain unchanged (like classic books on Gutenberg.com) then your keys could be URLs, and you enciphering/deciphering program could access the files directly over the Internet instead of as local files.

I think I will code up a C++ program to do some statistical tests on different ways to mix texts and see what happens.
Offline Profile Quote Post Goto Top
 
Grip2000
no member
[ *  *  *  *  * ]
Hi Fiziwig,

7.59 Fact -> A running-key cipher can be strengthened by successively enciphering plaintext under two or more distinct running keys.
For typical English plaintext and running keys, it can be shown that iterating four such encipherments appears unbreakable.

link -> http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf

http://s13.zetaboards.com/Crypto/topic/6882826/
Offline Profile Quote Post Goto Top
 
mok-kong shen
NSA worthy
[ *  *  *  *  *  * ]
fiziwig
Feb 13 2014, 11:20 PM
I think I will code up a C++ program to do some statistical tests on different ways to mix texts and see what happens.
Processing with a poly-alphabetical substitution (with all random alphabets) as you suggested would certainly lead to a better result than the mono-alphabetical one I have in my code. (My substitution is dynamic, in that the alphabet is modified on encrypting each character, but the same can also be done in the poly-alphabetical case).

I think it is essential to stress: (1) Such pseudo-OTPs could be practically highly satisfactorily secure, noting that one could, if desired, iterate the process, i.e. combining a number of first-stage pseudo-OTPs to obtain a second-stage pseudo-OTP. (2) The flexibility and convenience are apparently much superior than true OTPs in practice. (3) The result is not necessarily to be used for stream processing but is useful for general crypto uses, e.g. as a key for a cipher, etc. What is essential is that there is sufficient entropy. (It may be recalled in this context that natural language texts are estimated to have 0.6 - 1.6 bits per character.)

I am looking forward to learn the results of your experiments.
Edited by mok-kong shen, Feb 14 2014, 01:37 PM.
Offline Profile Quote Post Goto Top
 
jdege
Member Avatar
NSA worthy
[ *  *  *  *  *  * ]
XORing with a random stream will always produce a random output. The security, then, becomes entirely how difficult it is for the evesdropper to learn what is the random stream.

Conceptually, you could XOR with some offset into the digits of PI - and it'd be secure, until someone figured out that you were using PI as a key. At which point you've have no security to speak of.

So, the issue with respect to XORing against multiple plaintexts, or against an encrypted plaintext, is how large is the keyspace. When the evesdropper learns that you are, say, XORing against random locations in five random Project Gutenberg texts, how much work would it be for them to search those texts, looking for a break?

My thought is that it wouldn't be enough.

And that's assuming that they wouldn't be able to listen in to your traffic as you downloaded the files.
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Offline Profile Quote Post Goto Top
 
mok-kong shen
NSA worthy
[ *  *  *  *  *  * ]
The question of sufficient security is indeed difficult to answer (obtaining agreement), but I personally tend to think that on the other hand everything is after all "relative". It depends on many many practical factors, including the capability of the opponent and the effort spent by him, the time one's secret needs to be kept, what care the partners take in doing the work, etc. etc. Suppose e.g. a true OTP were generated with an occassionally defective appratus and one doesn't carefully check that, would there be good security? If one employs a sufficiently good key stream, for example with the method discussed in this thread, and a good cipher (in particular forgetting employing straightforward xoring, the context where OTP is commonly considered), then I suppose at least certain prerequisites for good security are present.
Edited by mok-kong shen, Feb 14 2014, 06:44 PM.
Offline Profile Quote Post Goto Top
 
fiziwig
Elite member
[ *  *  *  *  * ]
Grip2000
Feb 14 2014, 08:44 AM
Hi Fiziwig,

7.59 Fact -> A running-key cipher can be strengthened by successively enciphering plaintext under two or more distinct running keys.
For typical English plaintext and running keys, it can be shown that iterating four such encipherments appears unbreakable.

link -> http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf

http://s13.zetaboards.com/Crypto/topic/6882826/
This is deja vu all over again.

See this whole thread: http://s13.zetaboards.com/Crypto/topic/6882826/1/

And your post: http://s13.zetaboards.com/Crypto/single/?p=8012443&t=6882826

It seems like I'm re-inventing a wheel that I invented almost exactly 2 years ago on Feb. 7, 2012.

Well, I guess I'm getting to that age where I can't remember what I did yesterday! :lmao:

Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
« Previous Topic · General · Next Topic »
Add Reply