Comments

Evan HarperSeptember 18, 2014 2:23 PM

Is it really that bad? It's badly written, it gets the history all wrong, and it underplays the damage of reusing a cipher pad ("the difficulty of breaking the cipher decreases" is technically true in the sense that becoming instantly worthless is a decrease in security.) But it's not like insane, that I can see.

CyberkeurmerkSeptember 18, 2014 2:40 PM

This "article", for want of a better word, would have looked so much better when the word "cyber" had been applied lavishly. Now it's just a bunch of words with bad randomness....

haellowyynSeptember 18, 2014 2:58 PM

I would also be interested in an explanation oft what's so terrible, please. The one-time pad is the only theoretically secure cipher (we know of), as long as you have a random key that's as long as the message and is not reused. Sounds correct to me.

Fred PSeptember 18, 2014 3:38 PM

Basically, using a "Vernam Cipher" solves a problem that is no longer much of a problem, and substitutes it with a bunch of problems that are still big problems.

However, if you'd like an expert's opinion on the subject (I am not a cryptographer):

"If you think you know how to do key management, but you don't have much confidence in your ability to design good ciphers, a one-time pad might make sense. We're in precisely the opposite situation, however: we have a hard time getting the key management right..., but we're pretty confident in our ability to build reasonably strong algorithms."
Source:
https://www.schneier.com/crypto-gram-0210.html#7

garySeptember 18, 2014 3:39 PM

It's just yuck

- the vernam cipher describes any stream cipher, be it with one-time pads of random data, or a stream of pseudo-random data with a predefined seed
- one-time-pads with truly random data are uncrackable
- stream ciphers are crackable, and quite weak against chosen/known-plaintext attacks
- re-using keystreams is just very very bad

tl;dr vernam ciphers comprise both one-time-pads (awesome but unwieldy) and stream ciphers (generally MUCH weaker than good block ciphers), so the phrase "vernam ciphers are unbreakable" is quite dumb

AsmorSeptember 18, 2014 4:13 PM

I actually think one-time pads could be useful and practical in modern times.

Grab a few petabyte drives. Those are your one-time pads. Get them all in sync. Distribute them to whichever parties want to be able to communicate.

Those parties are now able to exchange up to one petabyte of information, with perfect security for transmission. The drives are still a security risk, of course. Would need to come up with some way of ensuring that no parts of the one-time pad were re-used, but that shouldn't be difficult. Just give each participant their own block which only they're allowed to use for encrypting.

cfSeptember 18, 2014 5:27 PM

@Asmor, they are, in many situations where what is being protected is worth the hassle you have to go through to properly implement the system. What you describe is reportedly how the US president's Washington/Kremlin/10 Downing Street phone lines have worked for decades. One time tapes in the old days, flown around the world under high security.

AnuraSeptember 18, 2014 7:30 PM

I encrypt all of my data by XORing with all zeros. It throws people off because they would never expect that it was encrypted.

AndySeptember 18, 2014 8:45 PM

Gawker/Jezebel/Jalopnik and all the other stuff is 98 per cent research and cut and paste by people of the intellectual maturity of teenagers. Only thing worse is the majority of comments.

When I click a link and see the Kinja design I shudder and close the tab.

AndySeptember 18, 2014 8:53 PM

Oh, regarding OTP...

Check out this modern approach to a OTP.

hackaday.io/project/1569-NSA-Away

Essentially, a simple RNG with two SD card slots generates the random pad on two identical cards. One is used in an airgapped Android to enter the plaintext. It uses the otp segment to encrypt, Displays the encrypted Version of the plaintext, then another separate phone is used with an App to read the cryptotext from the gapped phone via cam and OCR. Then you use the secknd device to either send it directly or you use the device as a USB HID on a computer to enter the cryptotext.

I think its neat.

Yusuke ShinyamaSeptember 18, 2014 9:22 PM

We should use another one-time pad to encrypt the first one-time pad,
and use another one-time pad to encrypt the second one-time pad,
and...

(I wish I could put this in a more humorous way.)

Nick PSeptember 18, 2014 9:23 PM

@ Andy

re OTP

It is neat. The camera trick I explored once, but figured it was too complex. Simple hardware connectors + protocols have less risk & complexity. The thing that jumps out at me is that this device uses commodity hardware, USB, and Android as its TCB. NSA has attacks on Android, subverted USB connectors, partnerships with phone carriers, and so on. For something supposed to stop NSA, they're leveraging an awful lot of what the NSA is already powning. Combining that much risk with the inconvenience of OTP's sounds like a sure way to fail in the market and security.

The better bet is to partner with a foreign device developer like the ones making MIPS tablets and custom phones. They could build some hardware that's a decent start by simply not including risky functionality & including a simple link. If PC's don't have it, a special connectors that converts between it and USB might be included. They could license something like PikeOS or OKL4 4.0 with trimmed Android running in user-mode. Two of them: private stuff in on, untrusted stuff like transport in another. Special applications in their own address spaces transfer the information with special care taken. And use a master secret that cryptographically produces other secrets that drive multiple block ciphers. Most of that code is already written, plenty of safety built in, & it keeps you from having to transfer tons of key material like OTP.

nobody@localhostSeptember 18, 2014 11:06 PM

@Chris Abbott

I one up you thrice over.

At first I xored everything with itself, then applied run-length coding to compress. The pigeons were impressed.

Than I realized that setting the length arbitrarily large, I could then decompress the encrypted archive to contain all data ever created--and all data which could ever possibly be created! When the length of my archive veered to limit of infinity, I filed copies of my archive with appropriate offices to register all possible copyrightable works, all possible patent applications for all possible inventions, etc. I also applied to be recognized as unbreakable world record holder for universe's largest library.

Finally, I memorized the number (zero) and the length limit (infinity) representing calculation of all possible finite binary strings. I now know the universal answer (although the question of decompression and decryption algorithm, is admittedly more difficult).

Unfortunately the NSA KGB Bilderberg Rothschild Rockefeller Morgan Carnegie Maltese Trilateral Masonic Gray Alien CIA conspiracy wanted to stop me. They realized that my archive also contained all possible terrorist plots, all possible child porn, all possible classified data, all possible designs of all possible superweapons, etc., etc. I don't know how they found I possess this archive; a parallel construction was made, a police officer observes me wearing a shirt in public with the symbols "0" and "∞". So don't try this, it is more dangerous than molten thermite lunch washed down with HF in a nice warm plasma sauna. Knowledge is danger. Information is danger.

I am currently seek expert witness to testify in my defense about pidgin nesting. My lawyer tells me my chances at least are better than the poor fellow who sent pi-in-binary to Wikileaks (jaja, tor was really slow that day). I rue the day I discovered the letter ^.

[p.s., on topic, the fore going was far more serious, sensical, and scientific than linked article's description of "Vernam Cipher" properties. io9.com == information malpractice]

Avalanche BreakdownSeptember 18, 2014 11:38 PM

@Asmor

Another reported use of OTP is for telemetry data during military rocket tests.

An example of an OTP tool that solves some of the key management problems you mentioned is OT7:

https://github.com/otseven/OT7

It addresses the possibility of key loss by adding a password and supports forward secrecy by optionally erasing used key bytes.

data whiteningSeptember 19, 2014 1:42 AM

randomizing telemetry data is to reduce bias.
so if data encryption is important, why not use a truly random sequence...

anonSeptember 19, 2014 2:18 AM

If 2 people who have previously met in person (shared key via trusted channel) want to communicate short messages (

When the number of users and/or messages increases, key management becomes more difficult. If untrusted channels are used to share key material, asynchronous cryptography will have to be added as an additional layer of encryption.

These are valid and substantial problems but OTP still has its place when limited to specific use cases.

anonSeptember 19, 2014 2:22 AM

I used a tilda in my last post which removed some of the text so I'm reposting.

If 2 people who have previously met in person (shared key via trusted channel) want to communicate short messages (e.g. less than a single page per message) for a limited number of times (e.g. less than 20x) ... then a OTP is a reasonable solution IMO.

When the number of users and/or messages increases, key management becomes more difficult. If untrusted channels are used to share key material, asynchronous cryptography will have to be added as an additional layer of encryption.

These are valid and substantial problems but OTP still has its place when limited to specific use cases.

Clive RobinsonSeptember 19, 2014 6:09 AM

@ Anura, Chris, Nobody,

Please use sarcasm or smiley tags, there are some reading on whom your jokes will appear as serious comments ;-)

Perhaps we should provide a link to the Obfuscated C Contest, where one of the entries used a failing of a software use of XOR to swap values without using a temporary variable to zeroise a key stream...

Clive RobinsonSeptember 19, 2014 7:42 AM

@ Wm,

With regards your above comment,

The OTP can be easily generated using a string that is known by both OTP operators.

Would you care to have a re-think / re-phrase on that...

As I read it, it says that some kind of algorithm working on the "string" generates a keystream which is determanistic not random, which would make it a Stream Cipher not a One Time Pad.

Richard HSeptember 19, 2014 8:00 AM

@Wm:

The OTP can be easily generated using a string that is known by both OTP operators

As Clive said, then it's a stream cipher with a key stream generated by the string, not OTP. Next?

The OTPed text is then re-encrypted with RSA

RSA as a block cipher? That's, ah, unusual.

nobody@localhostSeptember 19, 2014 9:11 AM

@Clive Robinson

The Underhanded C Contest is amusing, until one realizes that real underhanded c contest is in your kernel, drivers, etc. Your "TCB" amounts to millions SLOC, you have millions SLOC in ring0--but "You can hide a semi truck in 300 lines of C."

Still, you got me thinking. As OTP is inconvenient, communication partners usually use same implementation. For the today's textbook exercise, I propose a simple, easy-to-use GUI OTP program which has integer overflow in the pointer handling. Use uint16_t offset, you may excuse as "saving memory in the register file" ;-), and the keymat will be inadvertently reused every 65536 chars.

Add a custom protocol header to stop people accidentally trying to interoperate it with a real OTP program. Then send it to the io9.com staff, to get rave reviews on this "Military Grade Vernam Cipher Cryptor!!!11". EVEN THE NSA CAN'T BREAK IT*.

Not as elegant as (say) inadvertently reusing bits of k in the DSA sig code, but sometimes you need the NSA's help in standards making process.

Now, this was just an off the cuff idea. I'm sure, somebody here can do much better. Then we can open source this Military Grade Vernam Cipher Cryptor and advertise it as "Developed on SCHNEIER.COM**". If you feel charitable, offer binary packages which just install a textfile educating the user about security, with links to actual pretty good encryption program.

[* if you send a grand total of 64k or less data, ever.]

[** In blog comments section. Not endorced by Bruce Schneier.]

nobody@localhostSeptember 19, 2014 9:17 AM

@Wm

snake oil alert!

Each and every sentence of your post screams "snake oil" and violates the definition of a one-time pad. I didn't even check the links.

p.s., loosely speaking, the X Window system was sort of "written by MIT" and is super secure. ;-)

Fred PSeptember 19, 2014 9:18 AM

@wm - to quote Schneier, again

"Generally, products that claim to use a one-time pad actually don't. My guess is that the engineers quickly realize that they can't possibly implement a one-time pad, so they use the output of a stream cipher and call that a one-time-pad generator, or a virtual one-time pad, or almost a one-time pad, or some other marketing-speak. It's not a one-time pad. The security proof completely fails when you use a stream cipher. "

Source: https://www.schneier.com/crypto-gram-0210.html#7

If you are describing those programs accurately, they don't use one-time pads.

They are effectively stream ciphers, and unless they were designed as such, they're likely easily broken.

JustinSeptember 19, 2014 9:57 AM

@ Clive Robinson

Perhaps the keyed OTP scheme being described involves creating a legitimate random OTP from hashed and encrypted system entropy, then using that pad to encrypt the message, then sending both the message and pad using a symmetric cipher like AES (possibly after RSA key exchange to allow asymmetric encryption). After encryption with a truly random one time pad, the message should be indistinguishable from random data, as would be the pad itself, so if each of them is then encrypted by AES, then the cryptanalyst would not have any kind of known plaintext to work from for a round-by-round attack on AES.
This would leave the cryptanalyst with the computationally infeasible task of breaking a 128 or 256 bit random key by brute force.

This assumes of course that such an attack is possible (and knowing the NSA, it probably IS) otherwise, as this arm waiving is a waste of time.

In any case, you can more easily gain the same advantage by encrypting using AES in CBC mode with a truly randomly selected secret Initialization Vector, then Super-Encrypting with a second unrelated cipher like RC4, Blowfish, or Twofish.

This works because CBC mode XOR's the IV with your first block, so if the IV is a cryptographically secure truly random number, then that block is now protected by a true One Time Pad. Normally this protection only applies to the first block, even if you keep the IV secret, because the attacker can just read the cipher text for block one to see the IV for block two etc. - but if you add a second layer of encryption over the first AES-CBC layer, then the attacking cryptanalyst can't see the first layer cipher's ciphers cipher-text to recover the following blocks IV's. This has the interesting effect of extending the first blocks 'tough as an OTP' level of security to ALL blocks of the message.

What makes this mode OTP like in an information-theoretic sense, is that all succeeding blocks IV's are derived from the first blocks IV WHICH IS TRULY RANDOM. The only difference being that later block IV's have been encrypted one or more times by passing them through a block cipher. *** Now here's the fun part *** Since a block cipher is a keyed permutation, it can't really add or remove entropy (128 bits in map to 128 bits out) so all those other blocks are ALSO technically still truely RANDOM and therefore OTP encrypted as long we ALSO keep all the intermediate IV's secret (which is insured by the second layer of encryption).

So just as in the encrypted OTP exchange described above, the cryptanalyst doesn't have any way to do a round by round attack, and is left trying to brute-force both keys.

nobody@localhostSeptember 19, 2014 11:12 AM

@Justin

You describe what on its face seems a nice sounding scheme. Perhaps somebody with stronger crypto proof skills and lots of spare time can analyse it. But:

  1. I seriously doubt that is what the linked program provides (and will not waste my time looking at something which smells like snake oil).
  2. You say, "legitimate random OTP from hashed and encrypted system entropy". This also reduces in some ways to the security of the hash and encryption of the system entropy.
  3. The purpose of "one time pad" (and the implication of name "one time pad") is information theoretic unbreakable security based on providing 1 bit of entropy per 1 bit of plaintext. So what you describe, while strong, should not be advertised with a headline of "one time pad". I can indeed think of (and have heard of) very interesting applications of a "one time pad" type encryption for purposes other than the usual (sorry to be oblique), but smart people don't try to sell it as if it provides 1 bit/bit entropy/plaintext. And for the purpose you describe, you yourself note well, "you can more easily gain the same advantage by" carefully designed superencryption.
  4. Quoting your description of such superencryption, with emphasis added on the part you didn't pay attention:
  5. *** Now here's the fun part *** Since a block cipher is a keyed permutation, it can't really add or remove entropy (128 bits in map to 128 bits out) so all those other blocks are ALSO technically still truely RANDOM and therefore OTP encrypted as long we ALSO keep all the intermediate IV's secret (which is insured by the second layer of encryption).

    No, no, no. A keyed permutation of entropy is not new entropy! Write that on a sticky note and put it on your refrigerator, next to a quote from Von Neumann which comes to mind about states of sin. The only way to obtain 1 bit/bit entropy is to input 1 bit of entropy per 1 bit of plaintext. Period. Shannon says so and proved it. Your scheme reduces to some handwavy intersection between the security of the block cipher permutation, and the security of the second layer of encryption. I think it is probably very secure (note all the qualifiers), maybe unbreakable in practice, but it is not theoretically unbreakable in the strictest Shannon sense.

The problem is, I think, there are very interesting applications of OTP-like schemes. The waters are muddied by this kind of thinking, and all the snake oil out there. Good people get scared away from investigating OTP-like schemes, bad people take advantage, security loses out. Too bad.

0349xnr38xjx3x897nSeptember 19, 2014 11:14 AM

"the difficulty of breaking the cipher decreases"

This isn't even remotely logical/true. The probability of a side-channel attack increases because of the basic economics.. The difficulty of the cipher changes absolutely none..

I think there is one weakness in OTP: If you use a weak byte/letter generator in software patterns show and an attacker can generate the pad to length even if the generator changes entropy through the pad; it's actually not hard to wright a program to recognize bad byte level entropy if you know the x number of mathematical functions that can generate data pools and check against each; NSA likely has had this for decades.

IMO one-time pads are drastically under-estimated.. Stream and block ciphers are always going to be vulnerable to computational attacks even with decent entropy and RNG. It's pretty stupid to assume a government who has spent half a century fighting cryptographers of their own country are going to casually approve something they can't store and defeat..

nobody@localhostSeptember 19, 2014 11:52 AM

@0349xnr38xjx3x897n

You have no idea what you are talking about (or you do, and are trying to mislead others). The quote from the linked article, "the difficulty of breaking the cipher decreases" is a ridiculous understatement about reuse of pad material, which totally breaks the cipher. This isn't an advanced topic, and is not open to controversy. It is elementary "intro to crypto" demonstration to xor the two ciphertexts and remove the key stream.

The exact nature of one-time pad was analysed and proved by Shannon. If you argue with Shannon, Shannon wins. A one-time pad requires one bit of entropy per each and every one bit of plaintext.

The second substantial paragraph of your post boils down to "random number generators can be attacked". Why, you don't say! Every smart person knows random number generation is one of the biggest practical problems in crypto today. Which is why much discussion of OTP advises against using a PRNG (but then fails to discuss attacks on supposedly "true" random number generators, plus the difficulty of verifying them).

Your third paragraph is basic FUD. Since you are posting on Bruce Schneier's blog, I suggest that instead of hand waving about "always going to be vulnerable" (what isn't?), you point out to Bruce exactly where you see a break in his own Twofish. He will probably pin a medal on you, if you can do that.

P.S., I don't usually respond to trolls; but the comment I reply to is classic snake oil salesman disinfo, and could mislead people who have never heard of Shannon.

AnuraSeptember 19, 2014 12:39 PM

Basically, if you have a keystream k, and two plaintexts pa and pb, and you xor them both to the same keystream to give pn = n xor k, then pa xor p b = a xor b. Since a and b are plaintexts, this is equivalent to using a low entropy keystream. The more plaintexts encrypted with the same keystream, the more trivial it is to break.

JustinSeptember 19, 2014 12:48 PM

pnobody@localhost

Sorry, I don't think you understood the point I was making.

I was making a few very simple points:

1) If you take something RANDOM and run it though one trillion encryptions with a block cipher it's STILL RANDOM ... and contrary to the point you seem to be trying to make - IT DOESN'T MATTER IF YOU XOR IN MORE PLAIN TEXT.


2) So, if you take a 128 block of plain text then XOR it with a 128 bit secret key derived from a truly random source, then the result is unconditionally secure - doesn't matter if you then XOR the result with 10 BILLION bytes of plain text IT IS STILL SECURE. Got that? Otherwise any idiot could break an unbreakable one time pad just by adding more XOR's which doesn't any sense whatsoever.

3) It's also true that if you take the above XOR'ed ciphertext, and throw away the original copy of the random pad key, and throw away the original plaintext, and just consider the cipher-text as a NEW random pad- IT'S STILL JUSTS AS RANDOM AS IT EVER WAS (just as long as the original first random pad was truly random).

Where you DO get in trouble re-using key material is in the case where an attacker can gather multiple copies of cipher-texts XOR'd with the same keystream, which would allow the streams to be XOR combined to cancel out the encryption.

This does NOT happen in the CBC mode I proposed, because the intervening AES-CBC block encryptions in the first layer prevents simple bit wise correlations between blocks.

Theoretically, to the extent that the block cipher is not perfect in obfuscating the relationship between blocks, the IV could leak information between blocks, but if you are just talking about ANY SINGLE BLOCK, then the question breaks down to two simple points:

1) Is the IV to THIS block derived from a truly random value (answer: Yes, if the first block IV was RANDOM all other blocks inherit that randomness).

2) Can the attacking cryptanalyst gain access to the IV (answer: No, ALL block IV's are obfuscated by the second encryption layer)

So, block by block, the attacker must deal with the fact that each blocks plain text is first XOR'd with an unknown cryptographically strong random value that is hidden, so barring side channel attacks, there should be no way short of brute-forcing the key and original blocks secret IV.

This is true because as stated above in Lemma 1, 2, and 3 above, if the original IV is RANDOM, mixing it with plain text and then re-encrypting, even multiple times, will not make it any less random, so all the following blocks inherit an apperently RANDOM IV value from the first block, and this should remain true so long as the attacker can't gather and compare all those IV's (which is prevented by the second layer of encryption).

As you your mincing words about the 'true' definition of a One Time Pad, sorry being 'unconditionally secure' isn't part of it. Actually THAT KIND OF DUMB STATEMENT is probably the WORST example of silly snake-oil claims surrounding One Time Pads. Though secure in an information-theoretic sense, there are a hundred practical reasons why a On Time Pad might be anything but secure in practice. The 'real world' a One-Time-Pad will NEVER be 'unconditionally secure' because of these other factors (implementation errors, stolen keys, etc.)

The sole point I was making was, that the super-encryption scheme proposed does have 'unconditionally secure' elements, which combine with the properties of the underlying CBC block cipher to strengthen the composite cipher against cryptanalytic methods short of brute-force.

I wasn't claiming 'unconditional security' or that the composite cipher was 'exactly like a One Time Pad' or I wouldn't have mentioned a 'brute force' attacks on the keys and IV (you can't brute-force a one time pad).

JustinSeptember 19, 2014 1:12 PM

Anura • September 19, 2014 12:39 PM

Basically, if you have a keystream k, and two plaintexts pa and pb...

EXACTLY, though reusing the keystream is indeed insecure, it doesn't lead to an immediate outright break straight to cleartext - you are basically left with (Message-A XOR Message-B) so some effort IS required to separate and recover the plain text of each message - and YES this does become easier the more messages you can recover using the same keystream - so lighten up everybody!

And aside from perhaps somewhat under emphasizing the disastrous consequences of reusing key material, I actually thought that the technical definition in the upper shaded grey box was excellent.

nobody@localhostSeptember 19, 2014 1:31 PM

@Anura

Thank you for adding some rigor! Anybody not aware of what I meant by "intro to crypto" need to read that equation twice.

@Justin
(latest comment)

"some effort IS required to separate and recover the plain text of each message - and YES this does become easier the more messages you can recover using the same keystream - so lighten up everybody!" No, don't lighten up. Study symbol frequencies in natural language and run the stats. "some effort" in this context is very, very small effort to people who break codes as a job. Even when only two messages have been encrypted with same keystream.

@Justin

I may or may not have misunderstood your point. I would need to reread both your posts carefully (later; no time right now). Part of the difficulty is, you mix discussion of one-time pad (which has a very specific definition) with description of what may be a decent superencryption scheme. This is really the problem:

As you your mincing words about the 'true' definition of a One Time Pad, sorry being 'unconditionally secure' isn't part of it. Actually THAT KIND OF DUMB STATEMENT is probably the WORST example of silly snake-oil claims surrounding One Time Pads. Though secure in an information-theoretic sense, there are a hundred practical reasons why a On Time Pad might be anything but secure in practice. The 'real world' a One-Time-Pad will NEVER be 'unconditionally secure' because of these other factors (implementation errors, stolen keys, etc.)

Far from "mincing words", strict definition of a "true" one time pad is the means to teach people that information-theoretic secure one-time pad is in practice extremely difficult to get right, and brittle when wrong--fail badly at slightest implementation error. Bad RNG? Too bad, your actual security reduces to exactly the security of your random source. Reused key bits? Total break. Etc. That cannot be made clear, without precise definition of a one-time pad as 1 bit entropy per 1 bit of plaintext.

It is very important for people to know that (a) there exists exactly one cipher which is proved unbreakable, and (b) you are usually better off using a good block cipher etc. When you expand/dilute the definition of a "one-time pad", you open plenty of wiggle room for snake-oil salesmen to falsely associate utter crap with Shannon's proof of security. You lose the point that there does exist exactly one unbreakable cipher, and what they are selling is not it.

0349xnr38xjx3x897nSeptember 19, 2014 11:13 PM

@nobody@localhost: "The XOR operation is often used to combine the plaintext and the key elements, and is especially attractive on computers since it is usually a native machine instruction and is therefore very fast. However, it is difficult to ensure that the key material is actually random"

yep I sure don't know what I'm talking about..

Your argument against my economics statement is also fail.. I agree it IS simple which is why I pointed out it's only the basic probability of a side-channel where there is decent entropy used and the pad is reused, else it would suggest there is an attack on the cipher itself, obviously..

next

JustinSeptember 19, 2014 11:34 PM

nobody@localhost

(a) there exists exactly one cipher which is proved unbreakable, and (b) you are usually better off using a good block cipher etc. ...

Correct on point (b), not so much on (a).

Like Bruce has always said, bad crypto is simple and easy, but good crypto is complicated and difficult. So no one is served by oversimplifications.

Quoting Wikipedia:

"Several secret sharing schemes are said to be information theoretically secure and can be proven to be so."

Such a scheme can be turned into a an unconditionally secure cipher by dispatching multiple couriers, each with only a piece of the message.

This has the disadvantage over a One Time Pad that the key can not be pre-shared, but has the HUGE advantage that the scheme can be arranged such that an arbitrary number of intercepted messages will NOT compromise the theoretical unconditional security of the scheme.

And there are several other cryptographic constructions with information-theoretic perfect security, but they don't appeal to the snake-oil folks who focus like a laser on One-Time-Pads.

They like One-Time-Pads because the logic and math is really simple:

Take any set of arbitrary messages of equivalent length:

Humpty Dumpty sat on a...

Mary had a little lamb...

... and you can transform the first message into the second by flipping selected bits. This gives the OTP it's absolute security, since absent the key, we don't know which bits were inverted by the XOR operation, so depending on the XOR key the message could be literally ANYTHING.

It also shows a HUGE weakness in the supposedly 'perfect security' of a One Time Pad - Malleability.

Malleability means that if we can guess some plain text, then we can trivially manipulate a few bits to modify the cipher-text to substitute an alternate message of equivalent length.

So we could alter the cipher text of a message reading:

"Lets attack at sunrise"

So that it instead reads something like:

"Lets not attack rashly"

Given the malleability issue, and the huge key transfer and key storage issues, and given that there are other information-theoretic 'unconditionally secure' constructions, one might wonder, just what is the fascination with One Time Pads?

... could it be, because people who don't have the sophistication to understand the complex mathematical proofs for some of the more complex provably secure cryptographic constructions, CAN understand a simple XOR operation and the above "Mary had a little lamb", and "Humpty Dumpty" examples - then feel like big shots by saying, "All you cryptographers doun kno nuthin, because yuh'all is always guess'n about this crypto or that crypto, but I DO KNOW! Ha, ha, ha, I KNOW A CIPHER THAT IS THE 'ONLY' CIPHER THAT IS REALLY SECURE!!!"

Yeh, right.

For local files, OTP key storage is a significant problem (but gee, I put my key files in a folder labled "just random stuff, don't look here!" so I don't understand how my 'perfect cipher' got broken!) ... and for exchange of messages over a distance, key exchange is just as big of problem (gee I can't understand how my courier could sell me out like that!)

Again, my advise is to use something like AES-128-CBC or AES-256-CBC with a secret IV, then super-encrypt with RC4, Twofish, or Serpent and, baring side channel attacks or key compromises, you should be secure in a practical sense.

0349xnr38xjx3x897nSeptember 20, 2014 1:14 PM

@Justin: You and nobody@localhost keep suggesting you are correcting people even though you are literally just paraphrasing my "probability" statement..

OTP is vulnerable to economics of key management(side-channel) and bad entropy detection, that's it. Every piece of literature on OTP and Vernam research is just going to regurgitate these facts. Quit pulling up stupid arguments that are basically re-stating what the opposition has stated..

JustinSeptember 21, 2014 8:46 PM

Contrary to several comments here, the Vernam cipher was understood to be secure prior to Shannon's work, based on the trivial proof that, by selecting the appropriate key, any message can be transformed into any other message, which means that, absent that key, the attacker can't possibly guess which of the possible plain texts is correct.

Claude Shannon did do groundbreaking pioneering work in the field of information theory -- but the formal proof of the unconditional information-theoretic security of a fully random Vernam cipher one-time-pad was only a very minor incidental part of his work, which was only important because he formalized this proof in relation to other fundamental precepts of information theory, which he then went on to generalize to the whole field of digital communications in the presence of perturbing influences (i.e. how much data can we push through a channel in the presence of noise).

Shannon's contribution was to generalize the idea, and put it in the larger context of the underlying information theory, as a limiting case on the upper bounds on how much information will flow through a channel perturbed by noise (Eb/No vs. channel capacity). When the channel noise reaches the point were the error probability reaches 50/50 you are effectively reduced to guessing and no information transfer is possible. This is effectively what happens when you XOR plain-text with random data. For more information, look up Eb/No on Wikipedia and you will find all the math related to the Shannon–Hartley theorem.

This formula is at the core of all modern digital modulation systems, so there is no doubt that Shannon is indeed one of the unsung heroes of the information age, along with others like Alan Turing, and John von Neumann.

Please don't trivialize his work with all this silly name-dropping like his main contribution humanity was nothing more that being some kind of early disciple of your holy church of the One-Time-Pad.

As to the 'for all time' security of a One-Time-Pad encrypted message - Yes, this is perfectly true in the context of ephemeral information transfer. For ephemeral information transfer, it's great - if party "A" sends party "B" message "Z" and assuming that after decryption both parties then destroy all copies in existence of the key (and assuming there are no side-channel key compromises) - then any intercepted cipher-text would indeed be secure against decryption by an adversary 'for all time' (We still can't decode some messages encrypted this way in WW2, and never will unless the pad keys are found somewhere).

... On the other hand, ciphers are not just used for secure transmission, they are also frequently used for secure storage in persistent data storage, and in that scenario the 'for all time' security of a One-Time-Pad becomes a 'for all time' vulnerability. Because if anyone, anytime, EVER 'for all time' gets access to your massive store of key material then the encryption is worthless.

So, let's examine another scenario - let's suppose that someone has a top secret new invention worth billions, and reading all the posts here on this forum from friendly helpful self-appointed-expert-OTP-groupies, he (or she) decides that they will protect the information using the "only proven unbreakable cipher". So buying a second hard drive, they carefully fill it full of random bytes, and use those bytes to XOR encrypt their sensitive data. Then, realizing that the key data is also somewhat sensitive, they hide the key hard drive in the attic...

...What's wrong with this picture? What happens to his (or her) 'perfect security' when someone breaks in and steals both her encrypted drive *AND* to his (or her) horror finds the secret key drive hidden in her attic? How is this even the least tiny bit more secure that just hiding the drive with the private data in the attic in the first place?

On the other hand, if they had simply encrypted the data with AES-CBC-256, then Twofish-CBC-256, then RC4 and simply REMEMBERED the 60 character pass phrase (With mixed case alpha, digits, and funny punctuation) - and used a multi-round strong KDF with SHA512 to independently key all those ciphers - then how secure would that be?

With each of the first two ciphers using 256 bits of key, and secret 128 bit IV, followed by another 128 bits of RC4 key, then who ever stole her information would be looking at about 896 bits of keys that they would have to break.

Even if the wheels flew off one of the ciphers due to an internal vulnerability, and it was completely broken, the other ciphers in the chain would still protect the data, and you would still be looking at more than 512 bits of key to be brute forced.

To put that into perspective, let's get real creative and assume that someone could magically turn every atom in the entire earth into a quantum super computer that could examine a trillion keys a second - Got that? - Then we would be looking at cracking 1.33E50 (mass of earth in atoms) * 1E12 (keys/sec) or pretty close to 1.33E62 keys/second ... coincidentally, 2^512 is also equal to 1.3E something-or-other - in fact pretty close to 1.34E154.

The difference in the mantissa between 1.33 and 1.34 is pretty small, but that difference in exponents, well that does tend to make a difference. Enough difference that it will take roughly 1E104 seconds to try all those keys. Call it 10000 Google-Seconds. That's so many trillion trillion trillion of years you can't even represent it within the timeframe of the known age of the universe!

So let's see - I can ether OTP encrypt my data, bury the key hard drive in the back yard (or hide it in the attic) - and hope like hell that no one finds it - or use encryption that will almost certainly remain unbroken when our Sun has burned down to the size of a charcoal briquette - and just remember the key.

Not trying to belabor this folks, my point is simply that, though the One-Time-Pad can indeed be proven unconditionally secure under specific conditions, and may be a good choice under those conditions, this does NOT make it the right solution for most other cryptographic applications where it's practical limitations and vulnerabilities far outweigh it's advantages.

nobody@localhostSeptember 21, 2014 11:46 PM

@Justin

Thanks for the extended explanations. Much clearer now. I think you either know much more about crypto than I do, or you're really good at fooling me, or both--heh.

I wish to reply more than as following, if perhaps time will permit; you certainly put in quite some time to your explanations. I have a few quibbles and questions, and I think I learn some new things. But regardless, one thing I want made immediately clear, is I do not beat some drum for the "holy church of the One-Time-Pad" as you put it. Rather, I absolutely agree with your following paragraph:

Not trying to belabor this folks, my point is simply that, though the One-Time-Pad can indeed be proven unconditionally secure under specific conditions, and may be a good choice under those conditions, this does NOT make it the right solution for most other cryptographic applications where it's practical limitations and vulnerabilities far outweigh it's advantages.

I think I misunderstood you initially on certain points; I hope you did not misunderstand me. Let's put it this way:

Physicists argue about whether information can be truly destroyed if put beyond black hole's event horizon; let's assume it is so. I am stating, "the only physics theoretic secure way to destroy information is to throw it into a black hole. That's usually impractical, and you can hurt yourself trying. So just use a thermite block cipher, properly implemented, it's good enough. p.s., also don't try designing your own thermite containment chamber or block cipher unless you really know wtf you are doing; it you don't, it will break, and you will be badly burned."

Similarly, most people that sell the black hole data sanitization services are just snake oil peddlers. Maybe they hit the data containing equipment with a hammer a few times, and say it's compressed "like a black hole". Maybe they just throw it on the ground (hey, Earth has lots of gravity). Read ads for some things called "one time pad" or "like a one time pad" programs, does that sound familiar?

With all this duplicitous word play, I am becoming very strict about the definition of a black hole. If the matter is of lesser density than required to put it within its own Schwarzchild radius, then it is not a black hole. No, not if it's made of osmium. No, not even if it's a neutron star. These things have their own names, you know. And if a cipher does not provide one bit entropy per bit of plaintext, it is not a "one-time pad" by long-accepted definition.

I only raise Shannon to underscore this point, and not to trivialize his work as "the one-time pad guy". As I understand it, Shannon is one of the few men (only man?) in history to not only discover a new field of science, but to single-handedly lay down its entire foundation (and in extraordinary circumstances, at that).

Anyway, in reference to your other suggestion: I actually put my plaintext in the folder labelled "just random stuff, don't look here!" Then I xor the folder with itself, and throw it into a black hole. It's safe there. The one time pad I only use to sleep on, it's very comfortable iff I use each pad for one nighttime only.

JamesSeptember 23, 2014 8:12 AM

The problem with a Vernam cipher is that while the message is perfectly secure, the key needed to decode it is not.

With a one time pad, you need to distribute a new key for every new message. The more messages you send, the more keys you need to distribute, the greater the probability that someone will intercept your distribution mechanism and compromise your system.

This is known as the "Key Distribution Problem" and *that* problem is unconditionally insecure in a classical sense. If you have a key, you have a security problem.

Contrasted with a public key system, where the key distribution is unnecessary.

BTW, the Quantum Computer used to factor the public key encryption scheme doesn't take anywhere near that long to do it: qubits are evolved simultaneously not sequentially. Shor's Factorisation algorithm takes only log(n)*log(n)*log(n) where n is 2^512 on a 512-bit public key (so about 3.6million operations for full factorisation).

Quantum Computation comes to the rescue by using entanglement to distribute "random key generators" (the field is known as Quantum Key Distribution - QKD and one of the best implementations is BB84): if I perform a random operation on one of an entangled pair of qubits, the other qubit will change precisely, instantaneously and regardless of distance, opposite mine.

With that system, my "inflight message" can be perfectly encrypted using a Vernam cipher - Alice performs a random transformation with a random pad on a series of qubits that are entangled with qubits that Bob has. Alice and Bob then exchange a message. Bob uses his entangled qubits and measures the message, decoding it. If Eve attempts to intercept the key distribution she introduces errors into Bob's measurements, precisely measureable errors, BTW, kind of like a CRC. Bob checks his CRC and if it's damaged, discards the message and/or tells Alice to use a different channel.

The QKD isn't just theory either - BB84 has been used in practice at rates of up to 1Mbps and distances of 148km. It's been hacked too - by compromising the hardware used to generate the keys in the handful of commercial systems available (not hacking the math or physics, hacking the implementation).

Most articles talking about the future and using the phrase one-time pad or Vernam Cipher are usually referring to quantum cryptographic techniques leveraging QKD algorithms.

QSeptember 24, 2014 1:47 AM

@James • September 23, 2014 8:12 AM : `This is known as the "Key Distribution Problem" and *that* problem is unconditionally insecure in a classical sense.`

You might be interested in the proof which you can find on https://wuala.com/FreemoveQuantumExchange/Aspects/Security/Programs/SourceCodingExamples/Example.pdf

As you can verify, the needed true (quantum) randomness may also be public for unconditional security. This unconditional secure scheme solves the "Key Distribution Problem".

JustinSeptember 24, 2014 8:50 AM

@James

Although entanglement works instantly, the same quantum mechanics that postulates this also dictates that Qbits can't send any actual information faster than light. The reason is that when you collapse the quantum state by measuring it, you get a quantum random result that by itself imparts no useful information to either party.

It's easy to misunderstand, because the other party will always get an opposite result, which seems to be sending something but, without knowing your result this just looks like an equally random result to the party making the measurement at the opposite end.

The only way to make this random information valuable for key exchange or other information transfer is to transmit a conventional message using a traditional non-quantum side channel to compare notes with the other party.

For example if you measure your half of an entangled Quantum Qbit pair as a "1", and want to send that "1" to your distant party, you need to first infer that, since the distant measurement of an entangled pair inverts due to the complementary symmetry of measurements involving entangled particles, you need to inform the other party to invert the bit they just measured.

So, you effectively have to get on the phone and tell the other party to invert the value that they just measured, before it imparts any useful information, even though it just changed 'instantly' when you measured your member of the pair.

Without the side channel, the individual measurements are just random noise at each end - and since you have to send that side-channel communication via traditional means, and since the distant parties measurement is useless without this side channel information - *QED* you can't send information faster than light - SORRY.

This above is correct so far as the information theory goes, but greatly over simplifies the process. In the real world Quantum Key Exchange is difficult outside the laboratory, and is generally only possible over high quality fiber optic paths using polarization encoded photons (so much for getting an encrypted message on that airplane).

Even when transmitting over high quality optical fiber lines, there are big technical issues to be solved, the biggest one being this - THE SECURITY 'PROOF' IS A BIG FAT LIE IF YOU CAN'T RELIABLY SEND AND RECEIVE SINGLE PHOTONS (and, sadly, so far, we can't do that outside the laboratory)

Here is a really good link that explains Quantum Key Exchange protocols that have been tested over fiber optic cable using orthogonal polarization of photons (as in polarized light) to encode quantum states that theoretically can not be intercepted by a third party:

Quantum Key Distribution

The author explains the protocols used for Quantum Key Distribution in simple clear language without most of the hype and jargon, and why it's so difficult to realize the theoretical security potential of the method if you can't send and accurately receive individual photons.

Like a One Time Pad, QKD sounds great in theory, but only works if you meet certain conditions. In the case of a One Time Pad the rules are simple - you need one Shannon unit of entropy (i.e. one perfectly random bit) for every bit encoded - and for a Quantum Key Distribution scheme to be truly information-theoretic secure, you need to encode and recover each bit based on the quantum state of a single particle - But in the real world, communication systems always have noise, and transmission losses, so they can't meet the one-photon/bit requirement.

Let's say you encode your bits onto a half dozen photons, because that's the minimum your receiver technology needs, but Eve has a better receiver that only needs a photon or two, so she can siphon off a few photons, and read the bits, then decode their state based on the same clear channel oracle that Bob is using to read his bits, all without being detected, and there goes the 'unconditional security' of the system.

So, unlike a simple OTP, the rules and practices needed to implement that 'unconditional security' in a Quantum Key Distribution system are anything but simple and straightforward.

When they talk about 'privacy amplification' they are just arm-waiving and using traditional cryptography techniques to plug weakness that occur in real world protocols due to the fundamental flaw of not being able to implement true one-photon/bit QKD hardware in practical real-world systems outside the lab.

Given the limitations imposed by transmission errors, signal loss and noise in current real world QKD implementations, I'm not convinced that these current Quantum protocols can really claim to be unconditionally secure. They may be 'practically secure', so far as we know, after all the extra cryptographic processing - but so are traditional non-quantum key-exchange protocols, so far as we know.

JDSeptember 24, 2014 8:55 AM

I have found this entire discussion fascinating, despite the fact that I barely understand the basics of crypto...

Suggestions for books that anyone has read that are true intro to crypto books?

Random AlSeptember 24, 2014 11:52 AM

@Justin


Although entanglement works instantly, the same quantum mechanics that postulates this also dictates that Qbits can't send any actual information faster than light. The reason is that when you collapse the quantum state by measuring it, you get a quantum random result that by itself imparts no useful information to either party.

The reason we know that entanglement works to begin with is that
1) we can measure the change of the quantum state at the receiving end
2) we can match the new quantum state at receiving end to the quantum state at the sending end

The only thing we need, for binary communication, is a chance between two different states, and the measurement of those states.

Yes it is true, generally speaking, that measuring a quantum state can affect that state. This is has mostly been due to invasive measuring methodologies. The methodologies have been invasive simply because we have historically dealt with the location/momentum/etc of minute particles, and the only way to often measure their has been through some EM (or other) mechanism that (during the time of measurement) affects one of the non-measured parameters.

The changes in quantum states can be measured today, however. The only reasons to stop us from doing that are philosophical/quasi-religious, based on nonsensical interpretations of QM.

BnonymousSeptember 25, 2014 6:37 AM

@James
``using entanglement to distribute "random key generators" (the field is known as Quantum Key Distribution ''

Just to clear a myth, entanglement is NOT required for doing quantum key distribution (QKD). In fact, most practical implementations use what are called "prepare and measure" schemes (the first proposal of the BB84 protocol was also a prepare and measure type).

It's usually when you want to mathematically prove the security of the key exchange process that you invoke entanglement. But this is valid because entanglement-based and prepare and measure schemes have been proven to be equivalent (the transition merely makes the security proof easier to construct).


@Justin
``This above is correct so far as the information theory goes, but greatly over simplifies the process. In the real world Quantum Key Exchange is difficult outside the laboratory, and is generally only possible over high quality fiber optic paths using polarization encoded photons (so much for getting an encrypted message on that airplane).''

Although doing QKD is still not so easy outside the lab, your knowledge of how it is done is obsolete. Gone are the days when polarization-encoding of photons was the only means for performing QKD. There are several other degrees of freedom, such as time bins, relative phase, energy-time, that you can use much more practically to encode your qubits. There are network demonstrations (search for 'SECOQC' or 'Tokyo QKD network' if you are interested) that do work in real life environments albeit using dark fibers.

Also, recently, there have been both proposals and proof-of-principle implementations that allow QKD to be integrated in other practical environments including satellite links, conventional fiber-optic networks. See the links below (quite funnily, the last one is about exchanging a quantum key between an aeroplane and ground).

http://www.nature.com/nature/journal/v501/n7465/full/nature12493.html
http://www.nature.com/nphoton/journal/v7/n5/full/nphoton.2013.89.html
http://www.nature.com/nphoton/journal/v7/n5/full/nphoton.2013.46.html

WandeeNovember 3, 2014 10:27 PM

As usual if the OTP is involved tensions are running high and all the disciples that wait for a slap onto their shoulder from their master reiterate what has been regurgitated since he developed his dislike for the OTP - The OTP is pretty much useless.

Let me tell you it isn't; it is alive and kicking and providing a far better security as any of the super modern encryption systems or fantasies developed on this website. 1) The encryption key must be at least as long as the message. 2) The encryption key must be truly random. 3) The encryption key can only be used ones. (That’s when the One comes into the OTP and nowhere else.)
Shannon never defined an OTP that has to follow the rules developed in 1917 and patented in 1919, saying you have to have a message and pick now a key letter for each message letter. He looked at past, existing and potential new encryption systems but he never closed the mental door, as most of the commentators have done on this blog on a system, that might be called an OTP and following the three rules which I have mentioned above. Shannon did what a scientist should do (not like some of the pseudo ones here that have done beautiful cut and paste jobs, but seem to be incapable of producing one single thought for themselves) he questioned results even his results, but in no part of his paper he carved them into stone, saying that they are now a universal law.

Anybody that has actually an academic background and reading what Shannon wrote in the introduction to his paper, should be capable to spot the two points that suggest it is possible to have an OTP (I have highlighted them for the bloggers that have taken off their glasses) that doesn't provide a key distribution problem (no key at all for that matter); that isn't confined to the 26 letters of the alphabet (English language – other languages different numbers).

Shannon divided his paper into three parts. [....] The main results will now be briefly summarized. The first part deals with the basic mathematical structure of secrecy systems. As in communication theory a language is considered to be represented by a stochastic process which produces a discrete sequence of symbols in accordance with some system of probabilities. Associated with a language there is a certain parameter D which we call the redundancy of the language. D measures, in a sense, how much a text in the language can be reduced in length without losing any information. As a simple example, since u always follows q in English words, the u may be omitted without loss. Considerable reductions are possible in English due to the statistical structure of the language, the high frequencies of certain letters or words, etc. Redundancy is of central importance in the study of secrecy systems. [....]

We (I on behalf of our team) wrote to Bruce about a year ago asking if he was willing to evaluate an OTP that has been cleared of the restrictions he always pointed out. The reply had been three words "No Thank You", allowing me to repeat them here without having to summarise the reply. We had to knock at other doors to ask for an evaluation and here is one reply from an academic, who is a University Deputy Head, Computer Science and Software Engineering, Faculty of Information & Communication Technologies and who should be somewhat up to date as developments in computer science and also cryptology goes, since they are depending on each other in our days and are part of the subjects taught to students:
I'm not complaining - it's very good. I can't see any weaknesses at all.

WandeeNovember 8, 2014 11:02 AM

Justin # September 21, 2014 8:46 PM
Sorry for the belated reply to your comment but I had to read up on a second comment you made on this blog referring to Qbits and the wonderful world of quantum physics. I have to agree with blogger Bnonymous # September 25, 2014 6:37 AM after looking into it that your knowledge on the subject seems a bit out of date.
Still I am not commenting on that subject because my knowledge about it would not allow me to make a qualified judgment and refer that to people with more expertise. However on the Vernam cipher or OTP, as we might call it, I am a bit knowledgeable and so I found your rant leading from the Shannon–Hartley theorem passing the holy church of the One-Time-Pad towards the massive key storage very amusing; and the ending in the attic with a disk full of key data actually hilarious.
Your sixty characters phrase you have to remember exceeds the thirty two characters (256 bits) a proper defined OTP requires as a key to keep the secret and rest assured you want require more keys, that key doesn’t need to be changed, as long as sender and recipient can keep it secret. It will decrypt any future messages and there is no need for any further key exchange. It invalidates your comment that "The problem with a Vernam cipher is that while the message is perfectly secure, the key needed to decode it is not".
Your confidence about the trillion of years it would take to break an encryption you suggested has been voiced in the past; only at that time other systems claimed too that it would take millions or billions of years to break them by brute force. Unfortunately for them and the people that expressed that certainty, technological advances in computer science and mathematical algorithms changed that in a few years and for some it only took month to loose the status of almost certainly will remain unbroken.
Maybe you should not only revisit what Shannon wrote, but also read up on the mathematical algorithms developed that had the nimbus of being secure now and in the future. The only one that has stood its ground is the OTP. Any scientist claiming that his or her results will stay now and in the future has lost the status of being a scientist, since science not only requests to question one's results and the results of the peers in the field of science but it demands it.

TronDecember 21, 2014 5:55 PM

Why not just create a TB key, and assign each user a random key segment for that key file? You can limit which part/amount of the TB key each user gets to use up. Adding users would be a hell of a lot easier. And minimising compromised data would also be a lot easier. If Fred & Joe don't want Mark, Keith, John, & Amy to decrypt their message, they just don't share their specific key segment. They all have the same master key file, but are using very specific lines or patterns as a subkey.
And most people don't truly comprehend how long the OTP key lasts. How long would it take to use up if you only used it for texting, not sending files? A long fricking time..

I actually wrote my own MS-Dos vernam style encryption program. It's a batch file with calls to EXE & COM files for the fuctions I didn't want to code, or couldn't figure out. And it runs in a ram-drive (loads right off a thumbdrive), with the exception of copying the random keyfiles it generates for the pad(s).

And I didn't give the NSA a backdoor like Bruce.

So why don't you assholes quit ruining the comment section with your bullshit posts, and start sharing something usefull?

Gary RockmoApril 28, 2015 7:09 PM

I know this is an old posting by Bruce, but before you all get done with chuckling about how OTPs are purely academic because of the Key Distribution problem, you should consider that distributing the Key is not the problem.

A static Key (password) can be used repeatedly for a OTP construct.

Since all OTPs require a new Cipher, it is distributing the Cipher that is the problem.

If the Cipher is generated via randomly seeded PRNGs, as it should be, then it is a matter of conveying the seeds of the PRNG. This is entirely possible by embedding those seeds within the encrypted output.

In which case, the static value or PW is not a crypto generator, it is simply a conduit.

If one considers that in a quantum sense, the boson is simply a carrier of the force particle then we can equally consider how to use the seed initializers as a carrier values.

If the carriers are simply a multitude of byte reprsesentations, they can be elevated via any simple algorithm to seeds. We do not need to transmit the seeds, only the byte values, which can be embedded randomly (post modulo) within the encryoted string.

Consequently our PW is a conduit of embedded byte postions and reverse modulo values.

Since the 'Carrier Bytes' are randomly generated, there is no relationship between the PW and the Randoms. If the 'Carrier Bytes' are embedded based upon mLen and random padding, then no two encryptions of the Same Message will yield the same encrypted result.

I know you guys get constantly pissed off when any novice discovers OTPs and thinks they have a great new method. I don't blame you, I've seen some very questionable notions. and, I'm not a novice.

But, what I do not understand is the total sense of 'no point trying', or 'I'm only as smart as wot i got told!'

What happened to: 'If it could be done, how could it be done?'

At the time that Boer, Curie and Einstein were working on their respective projects, it was generally considered that science knew everything there was to know. Gravity, Electro-Magnetism, Evolution. So why bother doing anything new?

Many of the people that respond to Bruce in this forum are, like Bruce, advocates of NRYO. I simply can not undersatnd this. Until one rolls one's own, and then realizes what is wrong, and then goes through that rinse/recycle a number of times, only then can you say NRYO.

Probaly 99% of you that rip anyone for advocating something, or trying something, have never tried, never offer advice, never explain why.

Well, that's fine.

You can stay smug in your academic acheivements from 30 years ago when all you did was repeat what someone else told you.

But try doing something new.

Just supposing it was Diffie, Hellman, or Merkel that was simply asking, 'hey does this make sense?'

My guess is that you would defer to your Schneier Gods, and academic principle gods, and a chorus of "Never Roll Your Own" would ensue.

Have a nice life,

Rockmo.


Nick PApril 28, 2015 8:52 PM

@ Gary Rockmo

What are you talking about? In OTP, the cipher is the operation combining the key material from the pad with the plaintext. The pad itself must be truly random and can't be reused. That's why it's considered the key. If the pad isn't truly random, then it's essentially a stream cipher that other security models apply to (not OTP). If the pad is reused, that also breaks the OTP model by leaking information about the plaintext that aids attack.

So, as Bruce says, using one time pads just eliminates the "share this message secretly" problem and creates a "share this equally large key secretly" problem. If they can't trust distribution of messages, how are they going to trust distribution of equal sized keys to encrypt messages? So, he and many others accuse OTP's of shifting the problem from transporting messages to transporting keys with the same issues remaining. So, amateurs have to correctly implement a TRNG, OTP, and logistics scheme.

Or they can use one or more layers of unbroken, simple encryption with tiny keys. Then there's a ton of ways to move things that small with little difficulty. Yet, people keep creating new OTP's without solving their issues...

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.