One-Time Pad Encryption With No Pad?

thepooleboy writes: "The Globe and Mail has an article about a Toronto area company that has perfected 'Unbreakable Encryption' using the Vernam Cipher." The idea is to use as a one-time pad a large number generated by equations sent with an initial (proprietary) exchange which takes place when users connect to an equipped server. Since real one-time pads' numbers are by definition random and known in advance to both sender and receiver, though, the company seems to be playing fast-and-loose with their terms.

Comments

Pour me another cup of that snake oil!

[pointym5]

Depending on their "generator" function, they might have a decent cryptosystem or they might not, but IT IS NOT A ONE-TIME PAD by definition. Symmetric cyphers that aren't one-time pads can ALL be called "one-time pads" under that bogus definition, since generating a long sequence of random numbers to apply to the plaintext is pretty much what a cypher does.

And here I was just reminiscing fondly about ZeoSync the other day, when another scam pops up!

I doubt it

[Waffle Iron]

... equations sent with an initial (proprietary) exchange which takes place when users connect to an equipped server.

Otherwise known as the encryption key? That's hardly a one-time-pad.

Re:I doubt it

[Hater's Leaving, The]

Kinda sorta.

A one-type pad could be considered encryption key too though. The difference is that the theoretical kolmogorov complexity of a OTP is at least its own length.

If this nonsense can have it's 'pad generation algorithm' transmitted in b bits, then its kolmogorov complexity is at most b bits.

And if the algorithm is transmitted using a secure channel then the 'pad' is no more secure than that initial channel.

It's like the other old con - you can't use the tail end of a one-time pad to send the next whole one-time pad, no matter what they tell you.

So yes, you're right, the thing's just oozing bogons[*], and is fuxored from the start.

THL
[* The elementary particle of bogosity]

Sounds fishy to me

[happyhippy]

"We've found an electronic way of handling those complex keys, and of regenerating them dynamically so that lists of keys don't have to be stored anywhere," Mr. Kassam said. Its still going to be a matter of cracking what equations make the keys. And seeing everyone who uses these equations once someone has a good deal of these, everyones security is fux0red.

Re:Sounds fishy to me

[JediTrainer]

"We've found an electronic way of handling those complex keys, and of regenerating them dynamically so that lists of keys don't have to be stored anywhere"

Big fscking deal. They generate a random number, use that as a seed, and store the seed in a database.

Whooptie-doo. I can write that in less than ten lines of Java code.

No offense, but this is old news

[Hemos (editor)]

I read this right after the September Eleventh attacks on the WTC.

Thankfully, Google remembered exactly where the original article was at.

http://www.aspheute.com/english/20010924.asp

---
Partner Linux Site

Re:No offense, but this is old news

[SkewlD00d]

"Unbreakable" and "Encryption" is to "Unsinkable" and "Ship."

Re:'unbreakable' encryption

[kolding]

Actually, a correctly used one-time pad is unbreakable. The true randomness of the pad cannot be calculated, and if it's never reused, you have no clues as to how to calculate the encryption.

However, this scheme isn't a one-time pad. It's a function, with parameters encrypted with a standard encryption algorithm. If you break the algorithm used to exchange the parameters, you've broken the whole code. It's certainly no better than anything else out there.

I think we've been here

[fm6]

equations sent with an initial (proprietary) exchange

Since the exchange software is closed source, how are we supposed to know if it's secure? It's probably some silly gimmick that will be broken by the first hacker who fiddles with it.

Attempts to get around the fundamental limits of data encryption (and data compression, and a lot of other software fundamentals) remind me of all the pointless efforts to build a Perpetual Motion Machine. "Yeah, the smart guys say energy is "conserved", but anybody with any common sense can see if you just tweak this gearbox this way..."

Re:I think we've been here

[Citizen of Earth]

remind me of all the pointless efforts to build a Perpetual Motion Machine.

All you need is a cold-fusion generator that works at absolute zero. Then you can generate enough energy to increment through all possible one-time-pad keys. Of course, you'd never be able to match the raw throughput of an infinite number of monkeys unless you sicced the Loch Ness monster on them. But watch out for Xenu while you're doing that!

Re:I think we've been here

[fm6]

Actually, no. I had no idea how E-Book worked, and I was under the impression that DeCSS got broken because a licensee was careless about making a key accessible. I just had in mind the large number of vendors who are too quick to say, "It's secure. We know because we tested it. Don't you trust us?"

Now I can win $100,000!

[nsample]

I will use the secret powers of generating reproducable one-time pads to solve the equally overstated Bodacian challenge!

The world will be all mine, Pinky!

nonsense

[egomaniac]

They have a program which generates new keys for each subsequent transaction, and they claim that this counts as a "one-time pad".

Nonsense -- a one-time pad is only secure because there is provably no way to figure out the keys without a copy of the codebook (assuming they were generated through appropriate random means).

As long as a program is producing the keys, they will exist in a particular sequence. All you need to do is figure out at which point in the random sequence you are, and then you can generate the rest of the sequence easily, allowing you to eavedrop on the conversation.

Admittedly, the article was fluff, but key-hopping doesn't significantly increase the difficulty of breaking encryption. Unless there is something else behind this that I'm missing, this is another "Compress random data by 99%! For real this time!"

Re:nonsense

[geekoid]

"As long as a program is producing the keys, they will exist in a particular sequence. "

why?

Re:nonsense

[furiousgeorge]

"Anyone who considers arithmetical methods of producing random numbers is, of course, in a state of sin."

-John Von Neumann

This latest 'unbreakable encryption' and 'generated one type pad' crap is the same as all the rest. Please don't try to defend it. I predict it will be featured in the 'Snake Oil' segment of Bruce Schniers (sic?) next monthly mailing.

Re:nonsense

[Aqualung]

If the sequence is truely random

I think this is what he's taking objection to... generating a sequence that is random enough to provide a secure one-time pad on a computer is not a non-trivial task in itself.

Re:nonsense

[furiousgeorge]

>> generating a sequence that is random enough to >>provide a secure one-time pad on a computer is
>>not a non-trivial task in itself.

If you've generated it on a computer using algorithmic means then BY DEFINITION it is not a one time pad.

Re:nonsense

[MindStalker]

Because a computer can't truly think of a random number, if you have two identical computers and you ask them for a random number and give them the same "seed" they will produce the same number. If you feed them no seed at all if you boot the computer and ask for a list of numbers, it will be the same list everytime you reboot. The computer is just installed with a device to generate this sequence of numbers, it has no way to be original. When you need to create a truly random number, which is often important in encryption, you need a random seed, often things like keyboard input, mouse movements, and network traffic is used together to create this seed. Anyways, this program once it creates this random number has to send it back to the server for the server to be able to decrypt the messages. There is no secure way to do this except for using another encyption method, which makes this encyption method just as breakable as any other if you can get the random number, or the seed. But this company says that the encryption is absolutly secure, which it is, but the key for the encyption isn't secure. So effectivly they are hiding behind semantics

Re:nonsense

[curunir]

Because both the sender and receiver must generate the same sequence of keys. If it were random, then receiver wouldn't be able to decrypt the message.

It could be that the "program" that is sent initially that generates the keys is different for each user. This would make it slightly more secure, but if that "program" were intercepted then every single key it generates would be compromised. It would also be vulerable if the program which generates the program which generates the keys was in any way predictable.

Re:nonsense

[dracken]

No - Counter intuitive as it may seem, picking a pseudo random function at random to generate random numbers is only as secure as picking a random seed for *a* defined pseudorandom function and generating random numbers. This and more fascinating crypto stuff in "Foundations of Cryptography" - Some portions of it are also accessible here http://theory.lcs.mit.edu/~oded/ln89.html .

-Dracken

Re:nonsense

[egomaniac]

Clarification -- a whole book of codes is transmitted at once. Then you use each code once.

This is actually a lot better than it might sound, because you only have to worry about super-secure physical transit once, and then you get N opportunities to send completely unbreakable messages over whatever insecure channels you want. They could be announced on the nightly news if you wanted, and they would be completely and totally secure as long as nobody had your codebook.

(How can you prove they are "completely and totally" secure? Surely you can just brute-force a one-time pad? ... Well, no. Say the pad is 500 characters long, and you transmit cyphertext <= 500 characters. In the absence of the pad, you would have to try each and every possible pad ... which gives you each and every possible message. There are as many potential plaintexts as there are possible pads, and a huge number of them would be comprehensible, plain English. Comprehensible, plain English with absolutely no relation to the cyphertext, but you get the point.

There is no way to determine that "WE ATTACK AT DAWN" is the *true* plaintext, and not just some random coincidence that resulted from a certain choice of potential pad.)

Re:nonsense

[rm -rf /etc/*]

I remember the session on cryptography blunders at LISA last year. Two of the major blunders they listed were calling something unbreakable, and using a one time pad more than once. In addition to the problem you point out, from the description it sounds like they are using the pad more than once. If they client generates a key, uses it to encrypt data, sends it to the server, then the server uses it to encrypt data and send it back, it's not a one time pad. It's being used at least twice to encrypt and send data, which makes this much less secure.

Plus the fact that they are claiming it is unbreakable immediately puts it off my list :)

Re:nonsense

[Scratch-O-Matic]

But this company says that the encryption is absolutly secure, which it is, but the key for the encyption isn't secure. So effectivly they are hiding behind semantics

This reminds me of military radios with encryption. The standard key is good for safeguarding information up to the 'Secret' level. For some missions, they use special keys that are good for 'Top Secret'. You may think that those special keys are inherently more secure, in terms of crackability. It turns out they are exactly the same strength, but they are handled through Top Secret channels (in other words, you can't keep the Top Secret keys in a Secret safe; they have to be kept in the special building down the street, and the guys who key the radios have to have Top Secret clearance, etc.)

These guys' scheme is only as secure as their 'secret' method of transferring the keys. You can't carry a top secret key in a secret briefcase.

Re:nonsense

[quintessent]

Yep. The only difference between this and other key-based encryption schemes is that these people have made it obvious they don't know what they're doing.

Re:nonsense

[horza]

If you feed them no seed at all if you boot the computer and ask for a list of numbers, it will be the same list everytime you reboot.

I agree with the point you are trying to get across, though in practice if you feed no seed then most computers will use the real-time clock as the seed hence you won't get the same series each time (and it's pretty unlikely you will run the program the same millisecond after reboot).

Phillip.

Hrmm...

[Arcanix]

So essentially they send the keys to the unbreakable cipher using a breakable cipher, sounds completely secure to me.

Not a One Time Pad....

[alanh]

An algorithmically generated sequence of pseudo-random numbers is not a one time pad. They are misusing the term "Vernam Cipher" in the description of their product. Vernam/One Time Pads require truely randomly generated data, not a sequence you can determine with a small seed value.

People do this with hash functions all fo the time

[westfirst]

Cryptographically secure hash functions like SHA or MD-5 are often used to convert shorter, shared numbers (the key) into a long bit stream that can be xor'ed with the file in much the same way as a one-time pad. This is done all of the time.

Let k be your key. Let b1, b2, b3 be blocks of bits. Take as many as you need to encrypt the file:

b1=SHA(key)
b2=SHA(snip(b1)+key)
b3=SHA(snip(b 2)+key)
etc....

In fact, you can use any encryption function instead of SHA with a few tweaks.

Re:'unbreakable' encryption

[AgentRavyn]

Not entirely correct. Quantum encryption is unbreakable in traditional terms -- unless you know which photons are going to be used, and how to set your filter, you cannot crack it. Knowing those things isn't considered breaking the code -- it is on the level of actually having the key for the encryption.

My 26,740 Turkish Lira,

~ravyn

The weak point

[crush]

The client generates a series of random numbers to use as an encryption key. This is number is exchanged with the server through a secure process known only to Prescient, the server uses it to encrypt any information it sends back to the client,

This is where the action is. The rest of the press release is smoke and mirrors.

Re:The Past

[parc]

No, one-time pad is mathematically proven as unbreakable. It's the _ONLY_ proven unbreakable envryption method.

Things ARE random. The noise made by compressed gas escaping from it's container is an example. So is stellar background radiation.

Keyspace

[Rupert]

The Germans were using a variation on this in Cryptonomicon. The idea is that given an initial seed, you can generate a "key of the day" that appears random. In this case they're using an initial seed to generate a whole one-time pad.

However, it isn't secure. If you know the algorithm, you only(!) have to search the keyspace of the initial seed.

Re:Keyspace

[Rupert]

Unfortunately, a one-time pad has to be at least as large as the message it is encrypting (and random data doesn't compress well!). So you could do a Russian doll kind of thing with a really large OTP to start with, so you could encrypt a message and the next OTP, but your OTPs would get successively smaller. Better than nothing, I suppose, but still mostly more hassle than its worth.

Big deal

[meckardt]

An encryption algorythim using a one-shot key known to both sender and recipient is nothing new. Definitely has a higher potential security than other methods. But not very practical for repeat business (eg, a secure web store).

Re:Big deal

[merlin_jim]

Security is only potentially higher IF the one-time pad is communicated outside of electronic channels (ex: secured courier delivering pad directly into electronic safe), which is not what they're doing.

But, you're absolutely right about the above method (and any other secure one) being impractical in the real world; its generally only used for the most secret of secrets...

Re:'unbreakable' encryption

[Jack Porter]

Um, no. A one-time-pad is unbreakable. The idea is that you have a purely random set of bits (the one-time-pad) the same length as the data you want to encrypt. If you decrypt it using every possible one-time-pad you just end up with every possible message of the same length. If your message is "Attack at dawn.", with the wrong key you could decrypt it as "Retreat ASAP !!"

The problems are the "random" bit and distributing the pad from the sender to the recipient.

These guys appear to have a pseudo-random key generation algorithm, which by defintion isn't random at all.

WEBSITE LINK

[drDugan]

finding their website was non trivial on google

its here

http://www.prescient.net/

Re:'unbreakable' encryption

[Drakin]

Actually, it is possible to make unbreakable encription. At least in terms of text

Step 1: Generate a rather lengthy list of non repeating, as random as possible numbers.

Step 2: take the list and asign the letters of the alphabet in order along the list, (eg numbers in places 1 - 26 are assigned letters A - Z then 27 - 56 A - Z again.. and so on.)

Step 3: Make a duplicate of said list.

All communications are done with this code, using the numbers to represent letters, starting from the top, and use the number assigned to the fist instance of the letter, and proceed down the list for each use of the letter. (eg the first a would be the number in place 1, the second a would be the number in place 27)

As there's no pattren to it, it can't be broken. However, such a thing is so cumbersom to use, plus, there's the factor of how to get the list to the other party... Not a new idea, or even close to my own... read it in a book.

Re:The Past

[arkanes]

Nobody (at least nobody with any knowledge in the field) ever said that 1024 bit encryption was unbreakable.

Timothy: 1-1

[The Pim]

Ugh... A story about a real cryptography breakthrough, followed up by PR for this snake oil. Timothy, you should have stopped while you were ahead. ;-)

Re:'unbreakable' encryption

[spaceyhackerlady]

Anything which can be decrypted is going to be breakable.

Actually, no. A one-time pad really is unbreakable if properly applied. One way of looking at it is that since the one-time pad is random and was not generated by algorithmic means, no algorithm can break it. Crypto folks use different terminology, but the result is the same: unless you compromise the pad itself, no decryption can do better than random chance.

These results are well established, and any decent text on information theory will fill in the details.

An interesting side-effect of this came up with some U.S. decrypts of Soviet espionage activity in the 1950s, which were decrypted when agents misused their one-time pads. The authorities didn't take any action, partly because they were concerned about proving in court that the decrypts were accurate...

...laura

A vernam cipher IS unbreakable

[dwbryson]

no, a vernam cipher is the only form of unbreakable encryption. It happens like this: you have a stream of extremely random bits. And you have to make sure they are really really random, no pseudo random number generators. Say it's coming from a satelite up in space that measures radioactive particles(this was proposed in a paper not too long ago). Now the satellite streams these bits down to earth, so anybody can access them. Alice and Bob want to communicate securely over an insecure channel. So the agree on a series of bits to encrypt with. This can be anything from "every other bit" to a large polynomial function that says which bits to use. So every bit the function designates as an encrypted bit is used to XOR any message Alice and Bob use to communitacte. So, Alice computes bit random bit number x to encrypt bit y. She does XOR(x,y)->c and sends it to Bob. Bob also has this formula and performs the calculation to find which bit number x to use, then performs XOR(c,x)->y. The key is keeping the bit number function secret. Now, why is this secure? because anybody listening on the channel doesn't know the function(hopefully) and if your bits are truely random there is *no* way to distinguish whether any given bit can be 0 or 1. Try all the combinations for 0 or 1 in the message you want, but every permutation you want will look like the correct decryption.

Re:A vernam cipher IS unbreakable

[merlin_jim]

Ummm... no mathematical function is random. While you are correct, in that, given a random bitstream, every permutation you try will look like the correct decryption (and a large portion of them will generate something that looks like english, but isn't the original message)... the problem is the bit-choosing algorithm. You could take every bit, but then someone with access to the signal would be able to easily decode. You could take every other bit, but that isn't much more difficult.

You could use a large polynomial function; in that case, the amount of entropy in your encryption will be equal to the amount of entropy in your polynomials; if you can describe them in 128-bits, then that's the amount of entropy in your cipher.

Of course, all of this assumes that Eve intercepted the satelite signal at the same time.

Re:A vernam cipher IS unbreakable

[Linux_ho]

The problem with this is that anyone with the motivation, a disassembler, a good eye for assembly language, and access to the product can figure out the function.

Re:A vernam cipher IS unbreakable

[monkeydo]

This gets back to the problem of a new pad having to be exchanged for *every* transaction.
Where- if that's possible, then you must already have some secure means of communication and don't need to encrypt anything in the first place.

If I am a spy we can exchange the pad before I leave spy headquarters and then use it to transmit secret messages while I am in the field.

Re:A vernam cipher IS unbreakable

[Piquan]

BZZT, wrong, but thanks for playing.

You're making the same mistake that Precident made: the belief that any mathematical function can generate a random series of bits. The best you can do is pseudo-random. And using pseudo-random and thinking you've got an OTP is a very, very bad thing.

I don't care if you're using a satellite to create a convolution matrix, you're still using a mathematical function to generate the bits.

The satellite idea is based, pretty much, on the theory that "nobody can store all those bits for analysis". I won't discuss the practical merits of that, since /. already has. But it gives you no theoretical gain. You're stil l trying to call the output of a PRNG an OTP, and that just ain't so.

Re:A vernam cipher IS unbreakable

[merlin_jim]

While this has been an excellent read, and I thank you greatly for providing it, I would like to make a couple observations:

Firstly, the random function he produces depends on a 200-page equation using variables for exponents. The equation is deterministic, but random. If you provide the same exponents, then the halting probability will be the same every time. However, any particular value of Omega, when considered independently, appears to be mathematically random. This is good stuff, don't get me wrong. Provably random-looking numbers. VERY good stuff. But, for the purposes of cryptography, not useful, because in order to prove it secure, it has to be open; therefore, finding out how the number was generated is pretty simple, and your entropy is reduced back to the number of bits in the variables used as exponents, because that's your search space.

This WOULD be a great way of further increasing the entropy in a hardware random number generator, however.

*scoffs* 'unbreakable' encryption

[merlin_jim]

From the article:

Once the server is set up with E2Sec, anyone who logs on through a Web browser or Internet link will automatically be given an encrypted connection. A small 4- to 10-kilobit file, a bit like a Web cookie, is loaded into the client computer's memory. The file contains a program to generate random encryption keys, so that the keys themselves don't have to be sent over the network connection. The program is so tiny that even the low-powered processors in a cellphone can run it with ease, Mr. Kassam said.

This is really unbreakable. Unless you happen to intercept this program. Which wouldn't be that hard, and it may in fact be the same program for every client. And, they're touting this for wireless communications.

I found this next part interesting:

The client generates a series of random numbers to use as an encryption key. This is number is exchanged with the server through a secure process known only to Prescient, the server uses it to encrypt any information it sends back to the client, and then the key is destroyed and a new one is created. This process is repeated every time information is exchanged between the client and the server, making it virtually impossible for outsiders to decrypt the information.

It's a well established fact that non-open, secure processes are not secure. Cryptography is difficult, folks. The only way to even come close to proving that a particular process is secure is by exposing it to the scrutiny of the entire global community. Even then, its a case of proving that something is NOT true, which in this case involves incredibly complex mathematics that don't work for half of the proposed protocols out there; for instance, for a particular protocol to be 'provably' secure, it has to be time reversible (that is, if you apply any one step in reverse, the encryption key and cipher text each go back to their state before that step)

"We're 100-per-cent confident in our technology," Mr. Kassam said. "To give an idea of how difficult this is to crack, many organizations consider 128-bit encryption, which has a [cryptography level] of two to the power of 128, to be very secure. With e2Sec, we're talking about encryption in excess of 5,000 bits, and as much as two to the power of 10,000."

Ummmm... comparing asymmetric encryption to symmetric encryption (of which a one-time pad is a subset) with key-lengths is like comparing apples to oranges. In asymmetric encryption, your security is in your keyspace... every bit doubles the time to search the keyspace. In symmetric encryption, security is all about the keys; symmetric encryption is so easy to do that you can try millions of keys a second, as opposed to thousands or hundreds, so you HAVE to have a big keyspace. But, most symmetric encryption algorithms allow you to get it partly right; if the key is partly right, you get a partly decoded message, so the search algorithm is linear instead of exponential.

Re:*scoffs* 'unbreakable' encryption

[Citizen of Earth]

The client generates a series of random numbers to use as an encryption key. This is number is exchanged with the server through a secure process known only to Prescient, the server uses it to encrypt any information

Ha! The fools! Just send your message through this secure process. No need for the one-time-pad nonsense! QED.

Re:*scoffs* 'unbreakable' encryption

[cpeterso]

"We're 100-per-cent confident in our technology," Mr. Kassam said. "To give an idea of how difficult this is to crack, many organizations consider 128-bit encryption, which has a [cryptography level] of two to the power of 128, to be very secure. With e2Sec, we're talking about encryption in excess of 5,000 bits, and as much as two to the power of 10,000."

If their e2Sec crypto is more difficult to crack than 128-bit encryption, why would their algorithm need a LARGER key?? That implies that it is weaker.

Of course, the quote is probably talking about some snake oil "128 bits of OUR crypto is equivalent to 5000 bits of THEIR crypto." yeah, right.

Re:*scoffs* 'unbreakable' encryption

[swillden]

But, most symmetric encryption algorithms allow you to get it partly right; if the key is partly right, you get a partly decoded message, so the search algorithm is linear instead of exponential.

Whaaa? Only if the symmetric algorithm *really* sucks. With a good symmetric cipher, toggling any bit of the key or any bit of the plaintext should result in a completely different ciphertext (meaning, on average, half of the ciphertext bits change).

What you say is completely untrue of any good cipher, symmetric or asymmetric. While I'm at it, you also said:

In asymmetric encryption, your security is in your keyspace... every bit doubles the time to search the keyspace.

This is generally true of symmetric ciphers, but is not true for most asymmetric ciphers. For example, since every 1024-bit RSA key is produced by multiplying two 512-bit primes and every 1025-bit RSA key is produced by multiplying a 512-bit prime and a 513-bit prime your statement would only be true if there were twice as many 513-bit primes as 512-bit primes, but that isn't true.

The rest of your post was quite good, but you kinda fell apart in the last paragraph.

Re:*scoffs* 'unbreakable' encryption

[Dr. Spork]

Thank you! You are exactly right in both describing the system and diagnosing its fatal flaw. With standard factoring encryption, it doesn't matter who intercepts the message; they still have to do a lot of numbercrunching to decode the content.

With this revolutionary technology; all you get is the basic "security through obscurity", as witnessed in the sentence "This is number is exchanged with the server through a secure process known only to Prescient." Gee, I wonder how long it will take people to figure out the double-dog-secret process. If these Canucks are lucky, it will be during testing. If they are not, it will be a year after hundreds of companies, cell phones and whatever else standardize on this silly system.

Re:*scoffs* 'unbreakable' encryption

[merlin_jim]

First, I'd like to point out that I said most. This certainly doesn't apply to all. But, every symmetric encryption algorithm I've ever seen works like this: it takes a random-looking number and XOR's it with the plaintext to generate the cipher text. If you don't have a random number, you use your non-random number as a seed in a random-number generator to make it random.

But, if one were to use keylength as a measurement of the security of an algorithm; well, in symmetric encryption, if you get a certain number of consecutive bits correct, the result looks less random. One can assume therefore that those bits are correct, and start focusing on the rest of the bits.

Re:*scoffs* 'unbreakable' encryption

[merlin_jim]

Alright, I was reaching a little on the last paragraph; but the doubling-your-keyspace argument was right from Applied Cryptography

Re:*scoffs* 'unbreakable' encryption

[merlin_jim]

Honestly, I'm kinda hoping for the second option. I would never use this silliness to encode anything more secure than a shopping list, but as a security consultant, I can't help but thinking that one's failure is another's boon, and all that...

Re:If this works

[SquadBoy]

You have to read a 600 page book

http://www.cryptonomicon.com IMNSHO the best funniest geekiest book ever written. Basically during the WW2 part of the book they are using one time pads and one of the ways they are producing the random numbers is by having a Vicar's wife pull balls out of a bingo machine. Well she starts to peek and then the numbers are not quite random and so a German is able to crack their one time pads.

Re:'unbreakable' encryption

[Cheeko]

Actually a one time pad is mathematically proven to be secure. The biggest problem is that a protocol using it is much tougher to find.

A one time pad is completely random therefor you could take any message, "Bob had a car" and it could decrypt to ANY message of the same length, given the right pad. The biggest problem with a true one-time pad is that as the name implies it can only be used once, and needs to be the same size as the message its encrypting.

The best practical example of one-time pads is probably the hotline between washington and moscow. The crypto course I took explained that a very very large random one time pad was created to encode the message, and new pads are periodically created and taken by curier to each site. I believe a similar method is also used for transmitting launch codes to Nuke site.

Then again its been over a year, and my memory of the course is a little fuzzy.

Author should be ashamed

[tomstdenis]

Note to author: If you are not in the know, don't write as if you are.

First off, the OTP is completely 100% unbreakable [in theory]. Even with infinite time an OTP is unbreakable.

No symmetric key system, even a really super-duper one can get that type of security. I mean sure, you could make it require 2^1000 time, but that isn't unbreakable. That is "not likely to be breakable", a strong difference.

Second, this is not the first company todo so. In fact the sci.crypt snake oil journal is full of similar companies. Any company that cites "unbreakable" and "OTP" when talking about their inhouse crypto is very suspect. Real credible companies don't play on such naive terms. RSA for example will play on the reliability of the code more than they will about the breakability of their ciphers they use [e.g. RC5/DES/AES]

Third, if it is not a OTP then its not a OTP. These "OTP-like" and "pseudo-OTP" phrases you read here and there are meaningless. Either its an OTP or it isn't. There is no half-way inbetween.

Fourth, as I read it you download a program that generates a stream? This is nothing new. What the heck do they think a stream cipher is [re: a block cipher in CTR mode is a good candidate]. What they don't say is if you make a 1000-bit pad with a stream cipher you're not supposed to think of that as a 1000-bit key for a message as in you have 1000 bits of entropy. If you use a 64-bit key to seed a cipher to make 1000-bits for a 1000-bit message than the key is still only 64-bits and you just stretched the entropy over 1000-bits.

e.g.

Entropy In >= Entropy Out

Fifth, everyone please laugh at the shameful cloakware people. Shameful! www.cloakware.com, they are an even bigger canadian joke.

Tom

Snake oil

[yamla]

A one-time-pad is unbreakable provided that the pad itself doesn't fall into enemy hands. This is a fact and can be proven mathematically. Provided that you have one bit of randomness for every bit of the message, it cannot be broken.

This company is claiming unbreakable encryption because they have something like a OTP but have worked around the problem of having to transfer the pad itself. 'This is number is exchanged with the server through a secure process known only to Prescient'.

Okay, great. So now, instead of attacking the one-time-pad encryption, which we know is unbreakable if implemented correctly, hackers will now simply have to attack this 'secure process known only to Prescient'.

Snake oil. Their entire product really has NOTHING TO DO WITH ONE-TIME-PADS but instead, relies on a proprietary, secret algorithm that they won't tell you. At BEST, this is misleading. Their security is not unbreakable. It is far _less_ likely to be unbreakable than any other widely-known encryption algorithm. They are selling snake oil.

Re:Can't anyone use their heads at /. ????

[Em Emalb]

Dude, calm down a bit. You have very valid points, but if you insult the eds like this, the chances of a bitch-slap are pretty high.

thanks, and have a good one.

dubious

[zook]

From a quick scan of the article this seems doubtful as a one time pad. Maybe not completely worthless, though...

Certainly, a one time pad is only a one time pad if it is *truly* random. Unless the machine generating it has a true source of randomness---like a chunk-o'-radium or a pop-a-matic bubble---then they've just pushed the encryption somewhere else, and gained no security.

It still could be useful to generate such pads, since some devices (cell phones, etc.) don't have much processing power, and this is a way of offloading the encryption to a more powerful machine. Of course, you still need a secure method of transferring the pad.

But it doesn't sound like this is what they're doing, since they claim not to store the pad anywhere...

I'm dubious---encryption is only as good as the weakest link.

"Unbreakable" is to "encryption", as...

[volpe]

..."unsinkable" is to "ship"

Re:"Unbreakable" is to "encryption", as...

[dhamsaic]

Eh, except that some encryption is unbreakable. See HardEncrypt, for example.

Re:"Unbreakable" is to "encryption", as...

[dhamsaic]

I think you need to go read the webpage that I linked to, and more specifically, the link that details why it's unbreakable.

HardEncrypt is (let me say this again) unbreakable. Click the above link and read to find out why.

Re:"Unbreakable" is to "encryption", as...

[StevenMaurer]

You're right of course, but HardEncrypt is still useless, because one time pads are - for all practical applications - useless.

That's because, as soon as you publish the encrypted version of your file, your "one-time-pad" decryption key must be kept physically secure. And if you have to do that, you might as well have just kept the unencrypted version of your file physically secure in the first place.

This company is advertising a "have your cake and eat it too" approach, where an algorithm conveniently creates an "unbreakable" one time pad. It's nonsense. But so is the idea of using one-time-pads for security in any real sense.

Re:"Unbreakable" is to "encryption", as...

[swillden]

Eh, except that some encryption is unbreakable.

Yes. A one-time pad is perfect cryptography. Shannon proved this long ago.

See HardEncrypt [sourceforge.net], for example.

Not really. HardEncrypt is a one-time pad implementation. The thing about OTPs is they're only as good as the key bits. HardEncrypt tells the user to record some sound with their sound card and use the resultant file as the key (after a mixing step). This would work fine if sufficient care were taken to extract maximum entropy from the sound input and if the key size were no larger than the extracted entropy. Its documentation goes on at some length about headers in the sound file and the non-randomness they provide, but that's far from the only source of non-randomness. I'm not saying that a message encrypted by a careful user of HardEncrypt would be feasible for anyone to break, but based on the desciption, it's not a good OTP and there may theoretically be enough redundancy in the keystream to allow information to be recovered.

Re:"Unbreakable" is to "encryption", as...

[jbf]

Also, given finite memory, Rip Van Winkle can't be cracked:
http://citeseer.nj.nec.com/cachin97unconditional.h tml

Re:"Unbreakable" is to "encryption", as...

[NearlyHeadless]

That's because, as soon as you publish the encrypted version of your file, your "one-time-pad" decryption key must be kept physically secure. And if you have to do that, you might as well have just kept the unencrypted version of your file physically secure in the first place.

No, it is conceivable, because you may be able distribute the keys in a way that is more secure, but less timely than the message. The obvious example is a ship out on the ocean. If you sent them out with a CD-ROM filled with highly random data, you could communicate with them over the radio and still be secure.

Re:"Unbreakable" is to "encryption", as...

[fferreres]

I'm not really knowledgeable in this field, but doesn't a one time carry a disavantage.

I am just going on intuition but how can the receiver of the message know whether the source of the original message is trully caming from the expect source, and not a hijacked source.

Unless the receiver know what he'll be expecting as a message, i cannot forsee how he can be sure to be getting it from the right source.

Also, if he has to maint an interactive conversation, and can't know for sure what the source is, he could either:

1 - run out of pads (can't get the message)
2 - answering more than once with a pad (compromise the messages)

Even if parties have and infinite secuence of random pads, they can never know whcih ones the other party has already "wasted" in hijaked messages.

So to truly be called perfect encryption, there must be a way for perfect autentication of message sources, and this can be a problem. Of course they can agree on further rules for origin validation, but this imposes other vulnerabilities.

This is just a guess so don't slap my face please. Just point me in the right direction for further reading and I'll be glad to learn the answers.

Thanks!

Re:"Unbreakable" is to "encryption", as...

[fferreres]

Any other message would "decrypt" to random bits

What if you don't know what you'll receive? A binary file? A sound recording? And if it's text, they may as well bombard you with false messages, and if 1 makes sense, you lost the index.

For total certainty one can include a checksum prior to encryption.

Can't the other party do that as well? Unless it's a secret checksum algorithm...what if they the checksum gets compromised and you don't know? You may end up accepting false "messages".

sending this index (in the clear) along with every encrypted message

Is the index coming from the right source? The problem is still there i guess...

I can see the unbreakability of one time pads, but i can feel there are other disadvantages. What we have know can sign stuff and authenticate. One time pads cannot (by themselves)...

Re:"Unbreakable" is to "encryption", as...

[fferreres]

lowy, thanks for the answers. Looks really promising. The needing of a structure or authentication or validation is ok, but must be an integral part of any such implementation and carefully integrated so that it will hold that any possible decription is ok (else, the structure could provide a means to narrow the posssible messages).

Re:The Past

[merlin_jim]

I have two things to say:

1024 bit, while not unbreakable, is still unbreakable in the lifetime of the universe. I have no doubt methodologies and processes will be developped in the future that will change this, but as of right now, for all intents and purposes, it's unbreakable

Secondly, many parts of quantum mechanical behaviour *are* random, especially at macroscopic scales. For example, when a particular radioactive isotope chooses to decay is completely random; I've seen military random number generators that depend on this or similar effects to create truly random number.

But, no purely software random number generator will ever even come close to approaching randomness.

Re:buzz .. wrong

[zulux]

decipher this:

kjashduyqwhasklasj

Underneeth each letter I put the row of the keyboard that the key belongs to.

kjashduyqwhasklasj
222222111122222222

Thus usuing me l33t 5kilz - I have determined that your keyboard is missing its entire thrid row of keys.

Re:People do this with hash functions all fo the t

[westfirst]

What's missing here is a definition of snip(). It's a good idea to leave out many of the bits at each stage. SHA produces 160 bits, for instance. Let snip(b1) take the first 80 bits of b1 and ignore the rest.

Let + stand for concatenation.

Re:So what kind of Encryption protects the seed?

[crush]

Exactly. To look for the weakness in any of these schemes look for the bit that is "secret" or "proprietary". This is getting to be a tiring trend. Maybe /.'s editors could do us a favor and research some of these stories before they post them.

Take a secure method and add multiple weaknesses..

[Jelloman]

I'm no encryption expert but this whole thing looks pretty pathetic to me.

• "...anyone who logs on through a Web browser or Internet link will automatically be given an encrypted connection. A small 4- to 10-kilobit file, a bit like a Web cookie, is loaded into the client computer's memory."
  So the program is transmitted through breakable encryption.
  
• "The file contains a program to generate random encryption keys, so that the keys themselves don't have to be sent over the network connection."
  So the keys are generated using a pseudo-random number generator, which makes them quite guessable.
  
• "The client generates a series of random numbers to use as an encryption key. This is number is exchanged with the server through a secure process known only to Prescient..."
  Then the key is transmitted over the network via breakable encryption, which they just said they wouldn't have to do.

Very likely just rubbish

[tempmpi]

The file contains a program to generate random encryption keys, so that the keys themselves don't have to be sent over the network connection

Working OTP encryption requires the random numbers to be truely random, a computer programm can't do that. You need a source of randomness in the computer like the user or a special hardware random generator. The user isn't a solution for random numbers for OTP because you need a lot of random numbers and the user will have to type or move his mouse for a very long time until he has produced enough random numbers for a OTP encryption of a short file.

The client generates a series of random numbers to use as an encryption key. This is number is exchanged with the server through a secure process known only to Prescient, the server uses it to encrypt any information it sends back to the client, and then the key is destroyed and a new one is created.

Here the real problem of it. OTP encryption is only secure if no one can get his hand on the One Time Pad. If the OTP is transmitted over the internet, someone could easily get the OTP. If it is transmitted using a "secure process". The encryption is only as save as this "secure process". If this process is breakable, the whole encryption is breakable.

The "secure process" is also only known to Prescient. Everyone knows that "Security through Obscurity" doesn't work.

There's no such thing as Unbreakable

[Zspdude]

(IANAC) I am not a cryptographer. But... There's a couple holes in this which indicate that it is not perfect(and what is)?

The file contains a program to generate random encryption keys, so that the keys themselves don't have to be sent over the network connection.

The "book" method cannot be cracked by intercepting the message, true. How to solve this method? Steal the book. As has been pointed out in several previous stories of this genre, encoded data at some point has to be decoded and that makes it vulnerable.

The client generates a series of random numbers to use as an encryption key.

There's no such thing as a truely random number. There will be a way, no matter how difficult, to predict pseudorandom numbers. Especially if you've got a copy of the random number charts already. (Perhaps stolen the book?)

Exceptionally difficult to break, this encryption may be. But it is not unbreakable.

Re:If this works

[geekoid]

until your explanation, it was, in fact, not funny.

Re:Can't anyone use their heads at /. ????

[brer_rabbit]

I sometimes wonder if the eds intentionally post crap, just to get companies shot down. And what exactly will Prescient's venture capitolists say when they learn that the geek public thinks Prescient's product is worth crap?

I mean really, I doubt Timothy is trying to sell this to us. He's just preaching to the choir. And if Prescient was public he probably would of shorted a couple hundred shares before posting the story...

Re:'unbreakable' encryption

[arkanes]

What you're describing is an implementation of a one-time pad system. This is slightly different than the ones I know and may not be secure, but it's almost quitting time and I don't feel like looking anything up.

Re:The Past

[Nonesuch]

No, one-time pad is mathematically proven as unbreakable. It's the _ONLY_ proven unbreakable envryption method.

A one-time pad is only 'unbreakable' with the assumptions that your source of random data is truly random, and that the mechanism used to distribute the one-time pad to the parties is not compromised. The Prescient system may be flawed due to the latter: "This is number is exchanged with the server through a secure process known only to Prescient...". Without a secure mechanism to distribute the pad, one-time pad crypto cannot be considered secure.

Things ARE random. The noise made by compressed gas escaping from it's container is an example. So is stellar background radiation.

This is generally true. You can determine the ' random' output of any process by knowing the algorithm and all of the seed values. In the case of stellar background radiation, the initial values are assumed to be incalcuable.

One must assume that 'God' (Commonly defined as an all-knowing being) is capable of breaking one-time pad encryption systems.

I am not aware of any research into the creation of cryptosystems designed to resist compromise by supernatural forces, much less any system that can resist an attack by an omniscient, omnipresent, omnipowerful opponent.

"Mary, Alice and Bob wish to conceal their communications from Yahweh..."

Re:Can't anyone use their heads at /. ????

[Silver222]

On the other hand, some might say stories like this are a damn good reason not to subscribe. I read the National Enquirer in the line at the supermarket, but I don't buy it.

This is only "pseudo-random"

[rdmiller3]

The main strength of the one-time pad is that each and every element is as completely random as possible. The theoretical "amount of information" in a stream of such random data is approximately equal to the size of the stream.

This system is using a pseudo-random number generation algorithm, albeit a changeable one, which means that with a very small amount of data it is possible to completely predict the entire key stream. That means that the "amount of information" really contained in that stream is very small, since a small algorithm completely defines it.

This is what one of the other posters was referring to as "key space". How much information must be guessed in order to decode the message?

For these snake-oil vendors, the amount of information that needs to be guessed to decode a message is only as big as the pseudo-random algorithm (or likely smaller, since these guys obviously don't know what they're doing). If you crack the beginning of a message, you've cracked the whole message no matter how large.

For a real one-time pad though, the amount of information which must be guessed is as big as the entire message. No matter how much of the message you "crack", you'll have no more advantage to cracking the rest than you did before. Each element is random. There is no "method" to predict random numbers and so there is no way to crack a true one-time pad.

Re:Bad cryptography....

[mindstrm]

I am so sick of hearing that mantra over and over again.

Obscurity is one facet to security.

Obscurity on it's own is NOT security.

Given their method is proprietary and secret, you have no way of judging whether it is secure or not.

just as unbreakable as...

[greymond]

say oracle claimed to be ....

honestly no matter how or what you use to encrypt things given a long enough time span someone WILL break it

much like on a long enough timeline the average survival rate WILL equal zero

Re:'unbreakable' encryption

[cotodoso]

No, actually, a true Vernam cipher really is unbreakable. Check out the description of it in Bruce Schneier's "Applied Cryptography". The 'one-time pad' that was mentioned is a string of random numbers as long as the message that you want to send that is XORed with the message. Since XORing is a symmetric process (do it twice and you get back your original message), if you've got the random pad you can decrypt it easily.

That being said, the process they described in the article is not a Vernam cipher. It sounds like a variation on the Kerberos protocol, where the client and server machines exchange encrypted session keys.

There are also problems with the design, if you ask me. It looks like they are using the client computer to generate "random" numbers, which is a definite no-no. It also says that the keys are exchanged "through a secure process known only to Prescient". Sorry, but unless they have some sort of review by an independent party that proves it's
secure, it's an empty claim. Basically, this sounds like a lot of PR-hype that won't hold up to its promises.

cotodoso

Re:The Past

[Hater's Leaving, The]

However, the one time pad is simply a method of transporting a secure channel through time...

In order to have a one time pad, and be perfectly, provably, secure, you must at some point earlier in time (maybe face to face in a secret bunker, where there are no bugs or cameras or tempest devices etc.) have had a secure channel over which to transmit and receive the pad.

The pad lets you transport that secrecy to another point in time. However, you must have had the secure channel in the first place. Are you sure that bunker is as secret as you think it is?

So yes, it's mathematically proven, but it's often very hard to set up in practice, because the preconditions are strict.

THL.

Re:Can't anyone use their heads at /. ????

[ajs]

Mr. Pig Hogger,

The atrocious content of your sig not-withstanding, I ask that you read the whole article before quoting part of it in a reply.

Your comments were echoed by said editorial staff in the article as it appears on the front page.

Meanwhile, could someone moderate this karma-bomb down? I'd like to think that swearing a lot and then repeating a standard slashot rant (right or wrong) is not woth a positive moderation.

Thanks.

nonsense ... MAYBE

[debrain]

In an effort not to pre-judge - I looked at their whitepapers @ http://www.prescient.net/Solutions_e2Sec.htm

And their paper on this has some merit:
http://www.prescient.net/pdf/e2Sec.pdf

But I am not qualified to debate its merits. I don't believe that a public newspaper will have the technological background to satisfy the slashdot folk who like that sort of thing.

Re:OTP can be broken, given the right circumstance

[plam]

No, this is incorrect. OTP is secure in the following fashion:

Consider aaaaa as an OTP encryption of something. Then, hello and quack are equally good decryptions, and there's nothing that tells you what the original message was.

"One time pad"+modifications ISN'T A ONE TIME PAD

[IvyMike]

Dear Slashdot editors: A one-time pad is provably unbreakable provided you meet the very strict, precise definitions for what a one-time pad is.

Once you make the slightest change, it's no longer a "one-time pad", it's "a new unproven proprietary crypto system." There are NO exceptions to this rule. Any time you post a story that says, "Company X has a one-time pad system that is different than other one-time systems", they don't really have a one-time pad system, and you're just promoting their snake-oil for them. The OTP unbreakability is a mathematical proof, and you can't change the axioms and just claim the proof still holds!

Seriously, NO exceptions. Don't be tempted by their fancy footwork and wiley ways; they're trying to fool you

Can a company come up with a new cryptosystem that's cool? Yes, but they'll have to do a lot of hard work to prove it. This doesn't meet that standard.

When people first start to think about crypto...

[SIGFPE]

...they try to make up cryptosystems for themselves. A small minority come up with good ones. The rest of us tend to frequently come up with the same unreliable schemes. Funnily enough the system described by the article seems like one of these codes - it even has the same bullshit that beginning students will come up with to justify why their code is good.

Whatever the merits of this code - by definition it ain't a one time pad!

oh come on this isnt new

[HanzoSan]

RSA has been doing this for a long time.

Flat out lies

[Alsee]

The company is flat out lying. Or incompetent. They are *NOT* using one-time-pads, and they are *NOT* using a Vernam Cipher. If they were, then yes, it would be unbreakable encryption. But they aren't. They are generating a sequence of psudo-random numbers. Just like any streaming cypher. Generating a list of numbers and calling it a "pad" does not make a bit of difference.

Either (A) they do not understand cryptography, or (B) they are intenionally lying about their cryptography. Either case is a good reason not to trust their cryptography.

-

Re:WRONG

[swillden]

Given infinite time, a monkey will eventually bang out the contents of the OTP.

Sure. The question is: How will you know it when you see it?

The monkey will bang out every possible n-bit sequence. Applying them all to the n-bit encrypted message will give you every possible n-bit message. So you'll get all of the following:

• ATTACK AT DAWN
• ATTACK AT NOON
• EAT MY DORITOS
• LICK MY PENCIL
• I BROKE AN OTP
• ...

So, how, exactly, will you know when you've found *the* message?

That's why an OTP is provably unbreakable. Because every pad is equiprobable. And that's why no algorithmically-generated pseudo-random sequence can be used for a one-time pad.

Too brute to force

[fm6]

You can just do a brute force attack, applying every type of decryption technique with every key to the data until it is decrypted.

No you can't. Each attempt takes a finite amount of time. If you can pad the time enough (and some encryptions can be shown to take billions of years to fall to a brute force attack) you're effectively unbreakable.

Wrong.

[rjh]

Ummmm... comparing asymmetric encryption to symmetric encryption (of which a one-time pad is a subset) with key-lengths is like comparing apples to oranges.

This much is right.

In asymmetric encryption, your security is in your keyspace... every bit doubles the time to search the keyspace.

This much is nowhere near right. According to our best estimates at the present time, it'll take on the order of 2**80 operations to factor out RSA-1024. It'll take on the order of 2**128 operations to factor out RSA-3072.

Adding two thousand bits doesn't increase the difficulty by 2**2048... only 2**48. Asymmetric crypto does not double in difficulty with each added bit.

In symmetric encryption, security is all about the keys; symmetric encryption is so easy to do that you can try millions of keys a second, as opposed to thousands or hundreds, so you HAVE to have a big keyspace.

This is not correct. In fact, it's downright astonishingly wrong. The problem is you're assuming symmetric and conventional, non-ECC asymmetric keyspaces are both flat (they're not). But if they were flat, then asymmetric crypto would have a keyspace multiple orders of magnitude larger. Which is the opposite of what you're asserting here.

Conventional, non-ECC asymmetric keys are so huge because most of the keys are weak. Let's compare DES to RSA. Is 0xFA810DD0 a legitimate 64-bit DES key? Yes. (Note: DES only uses 56 of those bits for key material; the other 8 are used for parity.) Is 0xFA810DD0 a legitimate 64-bit RSA key? No. Why? Because 0xFA810DD0 is an even number, which makes it much, much easier to factor.

Conventional, non-ECC asymmetric keyspaces are so huge partially (not exclusively) because most of the keys in that keyspace are unusable. Symmetric keyspaces are so small partially (not exclusively) because most of the keys in that keyspace are usable.

A keyspace in which all (or the overwhelming majority of) keys possess equal strength is called a "flat" keyspace. A keyspace in which some keys are stronger or weaker is... well, non-flat.

But, most symmetric encryption algorithms allow you to get it partly right; if the key is partly right, you get a partly decoded message, so the search algorithm is linear instead of exponential.

This is so wrong that it staggers the imagination. Claude Shannon established some principles back in the 1940s which still guide cipher development today. One of these is called the avalanche effect. The idea behind the avalanche effect is that a single one-bit error, anywhere in the enciphering/deciphering process, will affect the output of half the bits in the entire e/d process.

Go ahead. Use Blowfish with a 40-bit key. (There are lots of Blowfish implementations out there; if you want one, email me and I'll send you one.) Encrypt it with one 40-bit key, and then decrypt it with a key that's only one bit different. You'll get absolute, total, gibberish. You'll get gibberish because Blowfish is a well-designed cipher and avalanches properly.

But wait--it gets even worse. Only a chump runs a cipher in electronic codebook mode. Usually, ciphers are run in a block-chaining mode, where every subsequent block gets XORed with the prior block. So if you have a one-bit error in your process, that will affect half the bits of the block... which then create errors in half the bits of the next block... which avalanche... which propagate their error forwards, on and on and on... etcetera.

You get the idea.

(All of the above information can be found in either Bruce Schneier's Applied Cryptography, 2nd Ed or Menezes, Oorschot and Vanstone's Handbook of Applied Cryptography.)

Re:Wrong.

[BeBoxer]

But wait--it gets even worse. Only a chump runs a cipher in electronic codebook mode. Usually, ciphers are run in a block-chaining mode, where every subsequent block gets XORed with the prior block. So if you have a one-bit error in your process, that will affect half the bits of the block... which then create errors in half the bits of the next block... which avalanche... which propagate their error forwards, on and on and on... etcetera.

Which is why everyone in the know realizes that chaining is pure folly. After a few passes, 100% of the output is in error, and you are looking at the inverted plaintext!

;-)

By the way, how are One Time Pads created?

[west]

Given the amount of data needed in a one-time pad, I can just imagine someone in the CIA firing up his computer program and saying "Give me 500 pages of one-time codes" :-).

Ask a certain pair of Nevada crooks

[A nonymous Coward]

All computer programs in slot machines and such are submitted (source, *source*) to some state agency, who examine the code to make sure it has no backdoors. One enterprising examiner noriced that a certain blackjack game did not reinitialize its random seed. He copied the random number generator code to his laptop, sat in a bar with a cell phone listening to his buddy report what cards came up, and within a short time knew what to play to win.

Both went to prison, as I heard it.

Re:'unbreakable' encryption

[monkeydo]

Please explain how you use a one-way hash to send large amounts of data.
My understanding of one-way hash functions is they are usefull for comparing information like passwords or digital signatures, but not encryption. If you hash a message and send it to me, I can't un-hash it (because it's a one-way hash) I'd have to guess what the data was and then hash my guess to see if I was right.

Re:Take a secure method and add multiple weaknesse

[rjh]

So the keys are generated using a pseudo-random number generator, which makes them quite guessable.

Not necessarily. ANSI X9.17 is both a specification for a PRNG and a family of PRNGs. The ANSI X9.17 generators I've used (and coded) in the past have passed every test for statistical randomness I've thrown at them, for datasets ranging from 16 bytes to 16Mb.

We do have good PRNGs. The biggest problem is that people don't use them, instead trusting in their own "proprietary and special" PRNG.

Not all ciphers...

[jbf]

Not all ciphers are long sequences of random numbers.

Block ciphers are bijections between Z_2^p and Z_2^p, where p is the block size.

Re:Not all ciphers...

[jbf]

a bijection is a function, not a number. "duh." The cipher itself is a random function (and inverse) generator, not an RNG.

And numbers are not "to the base x," they are "in base x." Get an education...

If you want to get really picky, a block cipher (with a key, in counter mode) is a list of 2^p elements of Z_2^p, which technically could be viewed as 2^{2p} numbers. But that's rarely how they're used; generally, in CBC mode for example, the "random number generator" actually depends on the input (and IV).

So, a (keyed) block cipher in CBC mode is NOT a random number generator. Hence, not _all_ (keyed) ciphers are random number generators.

That sinking feeling

[fm6]

Thanks to Hollywood, there are all kinds of myths about the Titanic that are "common knowledge". Like there weren't enough lifeboats because the ship was "unsinkable". In fact, the purpose of the lifeboats was to move people to a rescue ship, not to provide a haven. Imagine spending even a single day in an open boat in the North Atlantic! The accepted wisdom was that you could save more lives by keeping them on the liner until the rescuers showed up than by evacuating everybody to boats at the first sign of trouble.

That didn't work out, of course, and a lot of changes happened to make ocean travel safer. The "obvious" one -- more lifeboats -- is actually pretty unimportant. What is important? Safety training for ship's crew, disaster drills for passengers, the International Ice Patrol, and the requirement that emergency radio frequecies be always monitored. Complicated, boring, you'll never see it in a movie -- but these measures have saved thousands of lives. I'm sceptical that "more lifeboats" or "oh gee, it was sinkable!" saved even one.

I see the same oversimplification in encryption. Mathematicians who claim their algorithms are "unbreakable" are not in denial. They're simply thinking too narrowly. There actually are encryption algorithms that can't be broken (at least by any known attack). But "unbreakable" is only true in a certain context. You have to assume that keys are generated in exactly the right manner. That brings you into the real world, away from the pristine certainties of mathematics.

So in an absolute sense, there's no Unsinkable and no Unbreakable. But dealing with these facts is more complicated than people like to bother with.

Unbreakable encryption

[BarefootClown]

Unbreakable encryption is easy. I can write a program in under five minutes that will encrypt a file in such a way that I would be willing to guarantee, in cash, that it could never be broken. Simple algorithm, too:

for all bits n in the plaintext:
if(bit_n)==0
return;
if(bit_n)==1{
bit_n=0;
return;
}

Re:Unbreakable encryption

[jesterzog]

It is 100% reversible if you have the one-time-pad that caused the all-zero output to be generated. Assuming the method was XOR, the one-time-pad in this case would have coincidently been the exact inverse of the original message.

This is how one-time-pads work, and it's how they've been proven to be unbreakable if it's completely random and used in a flawless way that prevents outsiders from seeing the pad. (That's where the biggest problem is, and what makes them inconvenient.)

Having a one-time-pad that was generated by an algorithm is quite dodgy. Straight away it opens up the possibility of someone finding a way to figure out the algorithm and inputs that have been used to generate the pad.

Given enough example pads to work with, don't rule out someone spotting a pattern and figuring it out. Looking for recurring patterns that were generated by algorithms has been one of the most successful ways of breaking cryptography in the past.

Re:Unbreakable encryption

[swillden]

But you didn't propose your algorithm as a an "OTP Generator", you just said it was unbreakable encryption. At the very least, your algorithm needs to spit out the "pad". What you wrote was a program that just zeros all message bits and that is not reversible.

Having a one-time-pad that was generated by an algorithm is quite dodgy.

No, it's not dodgy at all. But it is also not an OTP. There are many stream ciphers that are quite good that work by generating a keystream with is XORed with the plaintext (RC4 is a very common example). Calling the output of a keystream generator a one-time pad isn't dodgy: its a bald-faced lie.

Given enough example pads to work with, don't rule out someone spotting a pattern and figuring it out.

For a real life example, look up the publicly available information about the NSA's project VENONA and its success against Soviet diplomatic ciphers. The Soviet messages were enciphered with a traditional codebook and then superenciphered with a one-time pad. However, the one-time pads were generated (IIRC) by secretaries pounding random key sequences on typewriters and there was enough structure in the resulting pads to allow U.S. cryptanalysts to decipher many messages. Even so, the initial break was only achievable because the Soviets reused their pads.

Re:Can't anyone use their heads at /. ????

[nusuth]

The fact that Slashdot was bought-out by another company doesn't necessarily make it non-free all of the sudden.

One step at a time, Cmdr!

How come editors post offtopic and get away with it? I've been rtlbed (or was it rtbled) for that.

But there are other choices

[kaladorn]

I have heard it suggested that sampling certain types of electrical/electronic/magnetic properties of the computer and synthesizing them (probably with a similarly random weighting) into a key could produce a truly random key.

Mind you, this is not exactly algorithmic... this involves data sampling from the physical univers.

I'm still waiting until we discover that _everything_ has an underlying pattern... then who'll be laughing last? *heh*

Horse petunia

[rufusdufus]

The thing described here is not unbreakable. The random bit generator could be co-opted. The polynomial function could be guessed or even deduced.

Re:Can't anyone use their heads at /. ????

[Pig Hogger]

Heyyyy, I've got none other than THE GREAT HEMOS himself!!!! I quote the whole thing, because it's a pity his post got moderated down to zero...
(To make sure it's really from HEMOS, just look at the parent post, which had been moderated into oblivion).

If you don't like it here, leave. Your dozens of pageviews per day only cost more money for Slashdot, and the fact that you don't subscribe doesn't help matters.

Au contraire, I loooove it here; that's why I have dozens of pageviews per day. (And he checked the access log before bitching to me).
And sour-puss comments like that by the editors certainly won't make me subscribe!!! (No wonder *ALL* my stories get rejected...)

I guess I could make a crontab job to reload the main page every 5 minutes or so. Naaah, it's not worth the waste of bits.

Fuzzy memories

[poemofatic]

tell me Adobe interlaced the word "encrypt" with the actual text, thereby claiming the work was "encrypted". Could just be an urban legend, but you gotta love it.

Truly Secure?

[guttentag]

Once upon a time 128-bit encryption was considered secure, and people told me my AirPort Base Station was worthless because it only supported 40-bit encryption.

Once upon a time, 1024-bit encryption was considered secure, until some guy proposed a plan that could get you a 1024-bit crypto breaker for $1 billion.

Some day, this too will be breakable, but there is only one truly secure way of protecting data that will never fail. It was described in Pulp Fiction:

"Your father didn't want them to find your birthright, so he he hid it in the one place he knew it would be safe: his @$$! And when he died of dysentery, he gave the watch to me and I hid this uncomfortable piece of metal in my @$$ for 4 long years. And now, little man, I give it to you."

Re:The Past

[Zeinfeld]

---This is generally true. You can determine the ' random' output of any process by knowing the algorithm and all of the seed values.

You haven't studied quantum mechanics, have you?

Actually that was pretty much Einstein's position. He refused to believe QM to be random and insisted on a determinstic universe.

The point is that QM theory does not and indeed according to itself cannot tell us wether the universe is genuinely random on that scale or whether there is a layer of hidden variables whose inner workings are not observable.

But getting back to the algorithm, the system described is not a one time pad, it is a stream cipher. I tend to avoid stream ciphers myself in favor of block ciphers. While there are good stream ciphers arround a stream cipher is much more fragile and much more sensitive to the exact circumstances of its application. The WEP protocol would merely be bad rather than broken if they had specified a block cipher. The reason they use a stream cpher is that they can be made fast.

Re:Can't anyone use their heads at /. ????

[zapfie]

It's because it's not really an editor, it's someone who is pretending to be an editor, that's why. Hemos is user #2, whoever this guy is is #520833, ergo it's not really Hemos whos talking to you there.

This is a STREAM CIPHER

[Eric Green]

First, the definition of a one-time pad: a set of random data the same size as the data to be encrypted, which is then XOR'ed (exclusive-or'ed) with the data to be encrypted. Both sides of the transaction must have previously exchanged the entire pad in some way. If the pads are TRULY random (perhaps via generated via quantum decay of atomic particles), then all possible plain-text messages are valid decryptions of the encrypted message, and knowledge of one part of the message (the "known text" attack) gives no knowledge of the contents of other parts of the message, those other parts equally have all possible plain text messages as possible decryptions -- i.e., it is provably secure.

But that's not what these guys have. They have a stream cipher -- linear congruent generators (pseudo-random sequence generators) on both sides of the connection. The "random numbers" are not actually random, because computers are detirministic -- given two computers identical programs, and identical inputs to those programs, you will always get identical outputs. "Breaking" a stream cipher generally consists of identifying the part of the encrypted text that has known text in it, extracting the key value of that part of the output, and using that to predict future or previous parts of the message. Thus design of stream ciphers is difficult, and you're better off using one of the tried-and-true designs of stream ciphers. For AEScrypt, I chose to use AES (Rijndael) as the permutation function, and CFB-128 as the feedback function that hides patterns in the output stream, with a 128-bit 'random' salt value to insure that the generated streams are not identical for two messages encrypted by the same AES key

It appears that their variation is that they have multiple algorithms for producing their stream of pseudo-random numbers. Does that produce more strength? Yes -- but less than you'd think. If you have two different algorithms, for example, that's basically a 1-bit addition to the key strength. If you have 1024 different algorithms, that's basically a 10-bit addition to the key strength. Big friggin' deal, you can already use 256-bit keys with AES, where the heat death of the universe will happen before you crack a message via brute force.

So basically these guys have a really clunky stream cipher, that they're calling a "one time pad". There's a saying in the crypto industry: simpler is better. That is, the more things you add to a cipher, the slower it goes, and the more likely that you made a mistake that ends up with the cipher broken. AES (Rijndael) is a simple and fast cipher that is easy to analyze mathematically. CFB to mask the output of a block cipher being used as an LCG is a simple and well-analyzed function. A LCG (Linear Congruent Generator) based stream cipher with 1024 possible brand-new pseudo-random generators (as vs. well-tested and well-analyzed ones) has 1024 possibilities for a "crack" of one of the generators (i.e., the possibility of predicting future sequences based on known text in a particular place in the message), meaning that all past and future messages using that particular algorithm are cracked.

This is offensive to me, in other words -- offensive from a language viewpoint (calling a LCG a "one time pad"), and offensive from a design viewpoint (adding unnecessary complexity that makes the design hard to analyze mathematically).

Snake oil. NEXT!

-E

Re:Can't anyone use their heads at /. ????

[Dr. Spork]

"[I]t's an "Alerting you to a lying company" story."

Then the point returs: who cares? Is Slashdot also going to alert us about inaccurate palm readers and deceitful telephone psychics? (Please don't submit a story with a headline like "Jamaican psychic Cleo claims she can accurately advise you on your life decisions" and then wait for readers to uncover that her claim is actually inaccurate.) Really, we should know better. The editors here should know better.

I wish we could see a list of the stories they rejected today. (Nothing from me; this isn't personal.) I think we'd then see there is a lot of real nerd news going on while we are being fed bunk.

Classic Snake Oil with = ~20-bit key

[billstewart]

This product has pretty much all the signs of the classic snake oil psuedo-one-time-pad, except that if you can believe their white paper, it's weaker than most snake oil products. Here are some of the issues:

• It's a proprietary secret algorithm they made up themselves. That's a bad sign already, because people who know the crypto community know that they have to be able to publish their algorithm and have it examined by (other) experts to have any credibility, and they know that any computer program can be reverse-engineered so the algorithm will leak out anyway, and anybody who doesn't know the crypto community well enough to know this hasn't read much of anything in the real literature, doesn't know the well-known attacks, much less the sneaky ones, and is probably reinventing yet another flat tire.
  
  
• They worked on it for four years before it was ready for public use. Since it hasn't been peer-reviewed, it's *still* not ready for public use. :-) And they say it's "considered to be the best in the world", but since they're the only ones who've seen the algorithms, they must be the one considering it the best in the world, and as we'll see below, their taste in such matters is pretty questionable.
  
  
• While grammar flames are normally considered tacky, if you can't get the syntax right in the English grammar in your press release, much less make the contents intelligible, and your crack team of engineers who've labored over this for four years can't hire somebody who *does* speak English to proof-read their press-release, I'm skeptical that they've done any better on either the syntax, structure, or quality-assurance for their programs. All your bits are belong to us! If they were from Montreal and not Toronto, you could at least blame it on Babelfish or something, but they've apparently had to do their own babbling.
  
  
• Their PR says it doesn't use an algorithm, and then talks about the computer programs that produce it. "E2Sec is not structured and uses no algorithms, therefore unbreakable" That doesn't mean that it doesn't have a mathematical structure - it only means that they're not mathematicians, don't understand the structures, and aren't very good at algorithms, therefore it should be easily breakable. That also strongly implies that, since they don't know algorithms or structure, they're not only bad at math but also not very good at programming, so the implementation has a much higher chance of being cracked without even bothering to crack their incompetent algorithm.
  
  
• They provide several examples of cyphertext (and the plaintext) and invite the public to break the algorithm using that, as a demonstration of their confidence that it's unbreakable. This approach is widely disparaged by the community - if they had any confidence, they'd not only publish the algorithm and invite cracking, they'd also pay some well-known cryptographer or cryptographers to analyze it for them, rather than hoping that either they'll get serious attention for free, or if they're a little brighter than that, only get unskilled amateurs trying to crack it because it's ignored by skilled professionals, leaving them free to say "See, nobody's cracked it in the TWO WHOLE WEEKS it was on the net! It must be UNBREAKABLE!!!!"
  
  
• They provide a "proof", which apparently was copied or translated by somebody who doesn't speak Mathematics, and leaves out the definitions of the critical functions and the lengths of variables but makes vigorous assertions that it demonstrates unbreakability within a person's given lifetime. The only way I can see that their assertion is true is if what they mean is "You won't be able to figure the precise values out in your lifetime because we've underdetermined our example" :-)"
  
  
• They assert that competing systems usually only provide 128-bit security, but theirs provides 5000-10000-bit security, because that's roughly the sizes of encryption programs they pass between client and server. Yes, that's an upper bound on the possible complexity, but most of those bits are the expression of the program, not the key itself.
  
• They pass their session encryption-pseudocode programs around using any conventional browser. This means that either it's all public, or that it's only protected by the 40-bit or 128-bit crypto used by the browser, so not only do they possibly have zero bits of strength in their own system, you might as well use your browser's encryption instead, because you can *i* get 128-bit crypto for free.
  
  
• "The core code is dynamically generated at install time from a random selection of over a million unique and distinct pseudo-code each capable of generating millions of server-based code." Unfortunately, in contexts that are clearly mathematically clueless, it's difficult to evaluate whether "over a million" means "20 bits" or "more than 5" or "billions and billions" or "oh, wow, man, that's really complicated-looking!". But if we take them at face value, they are at least *saying* that it's really about a 20-bit algorithm. It's possible that when you look at the algorithm closely that the 20 bits condense to much fewer than that, or that it's really a lot stronger than their clueless press-release (excuse me, they called this a "technology white paper", didn't they) writer says it is, but it's a good hint that it might be around 20 bits strong.
  
  
• Their algorithm uses "random numbers" and that they're "uniform". They don't talk about how they're generated, or how long they are. Typical random-number generation subroutines useful for game-playing or user interface decorations are linear congruential generators that are either ~16-bit or ~32-bit integers, and often the 16 bits are really just 15 bits. So maybe their 20-bit strength is really only 15. Of course, they also don't say anything about how the generator is seeded, so there's no way to tell if they've done that properly - it may be that their 15 bits of security falls apart after receiving two blocks of a message if they've done it sufficiently badly.
  
  
• In addition to using random numbers of undefined quality, they also refer to using "undeterministic keys". Aside from non-deterministic constructs in English grammar, it's hard to tell if they're referring to the presumed-poor-quality random numbers they use in other parts of the program or if they're doing some kind of hardware-generated randomness, e.g. having the user wave a mouse around. But if they are, the values from that randomness can't be generated identically by the recipient of a message, so they need to be passed in the aforementioned messages, where an eavesdropper can snag them, so the strength, if any, isn't helpful.
  

Re:WRONG

[Sycraft-fu]

Doesn't matter, it's STILL 100% secure (again assuming the pad is truly random). The thing is you just DON'T KNOW what it is that I'm trying to say in the message. Even if you can guess, it doesn't help you. You don't know what is plausable or not ebcause you don't know what I'm trying to say. IF you did, you wouldn't need it decrypted. Even if you have a general idea, it doesn't buy you anything. Suppose you know I'm going to tell the guy on teh other end to meet me at certian coordiantes. Fine, you don't know how I chose to phrase that, so you have nowhere to start in the decoding. However for argument's sake say you even know the exact for of teh message. You know I will write it like this:

"I will meet you at the folowing location: XXX XX by XXX XX" where the Xs are the degrees and minutes of the two coridnates. Still buys you nothing, you can decode those into any combination of cordinates you want and yuo have no way of knowing which one is correct.

The problem is with a one time pad, like the orignal poster indicated, literally ANYTHING within that space is possable and since it is truly random (if done right) you just can't know when you have the right answer. You might decode something that you belive to be perfectly correct, it looks totally plausable, and still be dead wrong. You'd do just as well guessing at random with messages the same length as the encrypted document.

Further, you have no way of knowing or being able to tell if what I send was in the form you expected. Maybe it's all BinHExed, maybe it's gziped, maybe it's ROT-15'd. You just can't know.

If you want to try it I'd be happy to generate you a message encrypted with a one time pad and you can try to crack it. I'll even be generous and tell you the prices format it's in and tell you what the topic is. You'll still never crack it, and that's more information than you'd normally have when dealing with a message so encrypted.

Other classic sign I missed

[billstewart]

Oh, yeah - "We've found an electronic way of handling those complex keys, and of regenerating them dynamically so that lists of keys don't have to be stored anywhere," Mr. Kassam said. If you can regenerate the pad of keys, you have no way to limit it to one-time use. With a conventional silk or flash-paper pad distributed by spies with briefcases handcuffed to their wrists, once you use a page of the pad, you burn it so nobody can regenerate it again. Otherwise, somebody else can also regenerate the key and crack your message.

And I didn't bother pointing out that because these folks have no clue what a mathematical proof is, they didn't bother showing how their system preserves the properties of a OTP algorithm.

DeCSS crack didn't depend on licensee carelessness

[billstewart]

The DeCSS break didn't depend on a licensee being careless with keys or code. Because the code is inherently contained in any software implementation, all that the 15-year-old kid who cracked it needed to do to access the critical data was decompile the code and analyze it carefully. He *may* hav violated his license in the process - it's not clear whether click-wrap licenses have any legal force in Norway at all, or even if they do, it looked pretty clear that Norway's laws about reverse-engineering override the terms of the license. The problem of obfuscating software-only implementations of code is fundamentally hard, though the DVD CSS folks could have designed a much more competent algorithm.

It's possible that the GSM crack did - I'm not sure if the pseudo-code that Ian analyzed over lunch one day, which he got off the net, was originally posted by somebody who violated his licenses in the process (or at least, how *badly* the alleged poster allegedly violated the alleged licenses :-), or whether the poster had access to the code because of a procedurally or contractually careless licensee. But even if that was the case, anybody who seriously wanted to crack the code could have probably grubbed the crypto algorithm off the chip in a phone, at the cost of a phone and a bunch of expensive chip-shredding hardware, though some of the authentication algorithms might have required examining a base station if they had been designed asymmetrically.

Re:nonsense ... DEFINITELY

[billstewart]

I wouldn't be bothered that if a small newspaper didn't have the technological background to avoid being snowed by this bunch of badly distilled snake oil, though the Globe and Mail is big enough that they should know better. It's important for papers to have technology writers or editors who at least know the difference between a press release, a report of a press conference, and a news article and can provide some objectivity by also interviewing one or two experts in a field to get some idea whether the company advocating their new product are really cool and clueful or whether they're selling total crockery (or both :-). Some newspapers have reporters with serious technical expertise (the NY Times and SJ Mercury News, for instance), and some make no pretense of doing objective journalism (name your favorite print-the-press-releases trade rag), and some are small enough you don't expect them to understand the technology (most small-town papers.) But even most small-town papers have local politicians and real-estate developers and used-car salescritters and ought to be able to occasionally recognize when somebody's trying to snow them.

The so-called technical white paper was one of the worst I've seen in ages.

I've been there done that

[Fjord]

I worked with a company that licenced the use of another company's "one time pad" encryption system. The long and the short of it is that it wasn't "one time pad". But the really important part was how the President/CEO of the encryption company honestly felt it was. No arguement (like the fact that an attacker only had to guess 4096bits to have all the information needed, and that analysis of data would quickly cut chunks of that down) could dissuade him from his belief. He had this whole, weird, meta logic that abstracted the problem out of the first tier (cracking the generated keys, which ostesibly were pretty random as individuals) but into the second tier (cracking the key generator, which was very structured and had 4096-bits of input). Because it was a meta problemone level up, he could see the problem, in the same way that Christians are fine with "God created the Universe" and don't see "Who created God" as a problem.

Re:The Past

[merlin_jim]

Bernstein had a fundamental problem with his proposal... basically the proposal is a diagram of how to make a large number of cheap (low memory, high speed) processors work together on a decryption. He does have some novel hardware devices that can speed up the process, but his supposed speed improvements all rely on one critical assumption:

That these processors are connected in a network that is zero-latency and infinite bandwidth.

The only way to truly provide something like that would be a network whose total bandwidth is greater than the combined clock speed of all the processors. That means that if you have 2^n processors, you need n network connections for each processor, in a large parallel array, commonly known in parallel computing as a hypercube. Let's say you build a machine of 8 100MHz 8-bit processors. Each processor gets 3 connections, all of which are 1Gbps. The total number of these connections are equal to the number of edges in a cube: 12, because that's how these processors are connected. Each processor is at a vertex and each edge is a connection. Add 8 more processors, and you get 32 connections.

For any machine sufficiently large enough to break a 1024-bit key, the cost would currently be greater than the entire economic output of earth for years. No doubt as high-speed networking technologies continue to be reduced in cost, this will change, but right now, Bernstein's proposal is unimplementable.

Brute time

[fm6]

Its usually possible to brute-force an algorithm

That's the umpteempth time that fallacy has appeared in this discussion. Doesn't anybody know about computability? Having an algorithm that is guaranteed to give you a result is not enough to give you that result. You also need enough time to run the algorithm.

Example: nobody knows whether chess is a forced win for white. Why not? All you have to do is run through every possible game. The famous Deep Blue could run that in a mere 10^100 years. Bearing in mind that current cosmology says that the universe will have collapsed by then. But maybe the steady-state folks are right after all...

Similar considerations apply to modern encryption algorithms. A brute force attack just won't work, provided the encryption key is long enough to force the necessary billion-year execution time.

Re:'unbreakable' encryption

[matrix29]

Anything which can be decrypted is going to be breakable. It may take a good deal of effort, but I don't believe there's any such thing as 'unbreakable' encryption. After all, the data has to be decryptable at some point or it's useless.

And what about the LIARS POKER method? This was detailed in a Scientific American article from a few years back. The idea is to create a huge randomized key which both senders have (ergo in the Liars poker game, two dollar bills serial numbers). The exchange begins with one side saying, "I believe if you add the digits at locations 567, 9984, and 12355 the resulting number is 13." And so on for a few thousand exchanges. Then the other sender gets the chance to play. Then they use known location data on the other person's computer which hasn't been exchanged yet in the previous inquiries to encrypt their data. The receiver then has only a small keyspace to translate the message back to the original.

The problems fall back to the need for a physical exchange of data files. That is why trapdoor encryption is just so seductive and ultimately doomed to be openly cracked like an eggshell in the next 12 years. Brute force is getting much easier with every innovation and stifling that is futile.

Re:WRONG

[swillden]

Which is why I said:

And that's why no algorithmically-generated pseudo-random sequence can be used for a one-time pad.

Learn to read next time, huh?

Not quite, but good idea. :)

[rjh]

The NFS doesn't care how big or how small the factors are--it just finds them. If 113 is a factor, the NFS will find it. :)

Re:Can't anyone use their heads at /. ????

[Restil]

Yay.. someone who noticed.

I have to admit though, the only thing more pathetic than someone faking an editor's name to draw hits to his website, are the hoardes of idiots who blindly believe who it is on name alone (the user # obviously isn't a bold enough hint)

*sigh*

-Restil