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.
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.
Mr. Kassam said Prescient has already piqued the interest of several corporations and phone companies. "We're cheaper than anything similar that's available out there," he said.
And worth the price, no doubt.
check out Non-Elephant. Gotta love that one-time pad model...
I am become Troll, destroyer of threads
nt
it would do away with the problem of the Vicar's wife peeking. :)
Note: Just because you don't get the joke does not mean that this is OT or that it is not funny. It is in fact both funny and very much on topic.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Finally, an unbreakable encryption. I have been waiting for this; it is certainly theoretically possible and I am glad is has been realized.
just a glorified press release, nothing but hype on this one. the thought of unbreakable encryption is a joke and if you buy into that, you'll do good in upper management or marketing.
This is my sig. There are many like it, but this one is mine.
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!
Otherwise known as the encryption key? That's hardly a one-time-pad.
decipher this:
kjashduyqwhasklasj
I simply used vocabulary larger than a message. No way you can decrypt this.
3.243F6A8885A308D313
"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.
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
I have a copy of "Applied Cryptography" somewhere, which is enough to spout off on slashdot as if I were an expert.
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..."
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!
We once thought 1024 bit encryption was unbreakable. Everything can be broken it just depends how much work you put into it. Also nothing is totally random.
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!"
ZFS: because love is never having to say fsck
So essentially they send the keys to the unbreakable cipher using a breakable cipher, sounds completely secure to me.
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.
- AlanH
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(
etc....
In fact, you can use any encryption function instead of SHA with a few tweaks.
I don't really see this as being a "one-time-pad" at all. You have a key that generates a pad, but the transfer of that key is just as vulnerable as any other encryption system.
Sounds like the passing of the key is hidden behind a proprietary protocol, that will only be safe for as long as the protocol remains secret. Once someone reverse engineers it. Encryption specialists learned back in WWII that the only way to have a good encryption system is to make an algorithim that is hard to break even after someone knows what the algorithim is. Secrecy never lasts forever.
Got Apathy?
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.
--
E_NOSIG
From my college coursework on crypto:
If they are generating the key with a program, then by definition it's not random. The best they could be doing is getting something poly-time indistinguishable from randomness. And, given that that is (IIRC) equivalent to proving P!=NP, I doubt they've done that.
Furthermore, if you have to exchange the keys by electronic means, you've defeated the whole point of a one time pad.
So, in other words, it sounds like just another attempt to dress up security through obscurity in fancy language.
Sounds like they have just invented srand(), i.e. they just provide a seed to a random number generator to both people. Sure, they can produce all the one-time pads they want that way. The trick is if people can 1) guess the seed or 2) intercept the seed as it is being provided to the other party. I'm not sure how any of this is original....
-Erik -- --This message was written using 73% post-consumer electrons--
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).
finding their website was non trivial on google
its here
http://www.prescient.net/
The body cannot live without the mind - Morpheus
"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."
Security in obscurity will never be secure.
A few links:
E2Sec Whitepaper (PDF)
Product Background (Word DOC)
I claim rightful first post in the name of logged in ACs everywhere.
Proprietary, secret algorithms? Security through obscurity is not security at all....
- AlanH
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. ;-)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
The basis of symmetric key crypto is a pseudo-random number generator. This is a deterministic function that, given a random seed, generates pseudo-random bits that, information theoretically, should be indistinguishable from random noise if you don't know the seed. There are many different implementations of PRNGs, and this company has just built another one. And PRNGs are not magic OTP generators.
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.
- "Never let a computer tell me shit." - DelTron Zero
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.
I am disrespectful to dirt! Can you see that I am serious?!
Lighten up. It's a story. I agree that it's a load of shit but that is why it was probably posted.
Your Lord, Jebus Christ
However, your security is not that of the resulting pseudo-random stream ( "one time pad"), it is that of the original key length. Secure, but calling it a "one time pad" is pure snake oil.
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
Someday, I'll have a real sig.
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.
Oceania has always been at war with Eastasia.
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.
Sent from your iPad.
I have been working my way through Applied Cryptography, in it he makes it clear if the pad ever repeats the system will be broken.
Now this system randomly generates an equation to generate the pad. Ignoring the question about the true randomness of this pad; wouldn't this system repeat equations every once and a while? If it does won't the plaintext then be vulnerable?
"The poet presents his thoughts festively, on the carriage of rhythm; usually because they could not walk" Nietzsche
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.
..."unsinkable" is to "ship"
http://www.interhack.net/people/cmcurtin/snake-oil -faq.html
Function XorEncode(ByVal StringData As String, SeedKey As Long) As String
Dim i As Long
Dim strTemp As String
Rnd -1
Randomize SeedKey
For i = 1 To Len(StringData)
strTemp = strTemp & Chr((Asc(Mid(StringData, i, 1)) Xor (Int(Rnd * 255))))
Next i
Randomize
XorEncode = strTemp
End Function
Oh, how friggin hard...... please.
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.
Many supposed crypto-breakthroughs actually boil down to simply moving your vulnerable channel from one time/place to another. In this case, the message itself might be "secure", but the the initial communication to establish the keys for that message won't be (and, if intercepted, can decode the entire message).
Shifting the point of vulnerability is a useful approach in many cases (maybe not this one). Its actually the basis of One-Time-Pad's effectiveness. In a normal OTP, you transfer the key first via physical travel, and then send the message electronically sometime later. This allows you to impose physical security on the key (your courier is well-armed!!), which then extends up to the later message itself.
However, that only works if the participants are willing to go through the extra hassle and delay of recieving pads by armored car. (And they pay the deliverymen too much to be bribed, etc...). It's unlikely that a commerically successful business could be built from this, since customers won't be likely to wait that long. If you try to transmit your pads over the internet, as opposed to some "inherently trustworthy" medium, then the only benefit over regular cleartext emails is the extra latency it'll take for hackers to decide that E2Sec is an interesting target.
So the program is transmitted through breakable encryption.
So the keys are generated using a pseudo-random number generator, which makes them quite guessable.
Then the key is transmitted over the network via breakable encryption, which they just said they wouldn't have to do.
Throw in some salt and CBC to mix things better ..
3.243F6A8885A308D313
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.
Don't let the door hit you on the way out.
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.
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.
Jan
A one-time pad encryption is easy, fast, and works GREAT. No key exchange is needed. The pad need not be known be either party, really, and can be truly random.
Decryption is more difficult...
Number of times 'fuck' was used in the post: 6 times
Number of exclamation and question marks used: 9 times
Using the word 'fuck' with lots of punctuation to sound like you know what you are talking about: Priceless
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.
What's in a Sig?
The "security" of this depends entirely on how secure each decryption tool is on each side of the transmission.
Not only that, but compromise of one side comromises the other side, meaning that although you have a secure box on your end, if the other box isn't, then the information sent can be just as vulnerable as any unencrypted data.
This isn't exactly a breakthrough either, since it's based on an old system that even an 8 year old could conceive given time. In fact, remember decoder rings? Same concept, though on a much larger scale.
And this method still doesn't solve the problem of establishing an unbreakable communication line over a medium such as the Internet. In fact, I'd hate to say it, but because the security of the transmission relies on the security of either side, I don't think this is even newsworthy.
The complexity of each random page in the "book" makes it nearly impossible to crack the code. And even if someone intercepts the message, there's no pattern to it that might help them decode the entire transmission.
...
No, it's the randomness of the data on the page that makes it impossible to crack, not the complexity.
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.
Game over. If the keys are being generated by a program, then they aren't random.
First, a special encryption system is added to a company's server. It can be used to encrypt things like e-mail, e-commerce transactions and Web browsing sessions, or more complex communications such as access by mobile workers to corporate mainframes and databases. The application takes a couple of weeks to set up on average according to Mr. Kassam,
Translation: The application takes a couple of weeks of billable hours to set up. Christ, how much Quake can those engineers play?
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.
First, no program can generate random encryption keys. Every software random number generator creates patterned numbers. Claiming that this system is like a one-time pad is nothing short of complete fraud!
"Competing systems have to have a lot of processing power available, because they do a lot of number-crunching as part of the encryption and
decryption process. But this program is mostly a complex number-generator," he said.
Translation: Competing systems have to have a lot of processing power available, because they perform strong cryptography.
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,
Got that? The entire system is dependant on no one ever reverse-engineering the key protocol!
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.
I wonder if any of these engineers have any crypto design experience whatsoever.
The system can be accessed with any standard Web browser, but Mr. Kassam said his company can also embed the security system in chips for cellphones, handhelds, network cards and modems. For example, he said security-conscious companies might choose to issue special e2Sec-enabled modems or network cards to any employees who must access a company network from home or on the road.
In other words:
1) They are depending on no one reverse engineering their key transmission algorithm.
2) The key transmission algorithm is published as a browser plugin.
They must have one hell of an industrial strength click-through license to prevent anyone from reverse-engineering their browser plugin!
A team of engineers at Prescient worked on the system for four years before it was ready for public use, Mr. Kassam said.
Not cryptographers, but engineers designed the system. That would explain the laughable design. CSS anyone?
"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."
128 bits beats 5000 bits from a pseudo-random generator any day. Besides, if they were really "100%" confident in their scheme, they wouldn't depend on the keys being transmitted "through a secure process known only to Prescient."
Mr. Kassam said Prescient has already piqued the interest of several corporations and phone companies. "We're cheaper than anything similar that's available out there," he said.
Finally, the punchline. Not only is our Sekret Protocol algorithm Leet, but it's CHEAP!!
Well, I suppose you get what you pay for
Congratulations, dumbass
This is clearly bogus. By definition a one
time pad has a shared set of encryption keys
at the sender and the receiver. So when the
article tells us: "with nothing installed on
the client side" you know immediately that
it is not a one time pad, which by definition
has "software" on the "client" side. Perhaps
they are sending the "pad" over a channel, but
then the encryption is only as secure as that
channel.
Of course, it would be possible to have a
secure channel, (such as downloading the pad
at the office into your laptop), but if it
is going over the PSTN then it is only as
good as that link's cypher.
Should also say, that this software seems to
use generated "random" digits. Clearly then
breaking the generator function also compromises
the "one time pad." However, it should be noted
that there are devices that can generate truly
random numbers, and these could, in combination
with a secure channel (bring the laptop to the
office) offer genuinely unbreakable encryption.
Do you work for that snake oil salesman Mr. Kassam?
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...
You're supposed to drag it through months of red tape first..
The Logged In Anonymous Coward
Specifically, if an equation is used, it's not a one-time pad because the data was generated deterministically. Duh. You need real, unrepeatable random data. Computers using only math functions can't possibly generate this.
Simply XORing or otherwise slapping pseudorandom garbage over plain text does not make a secure system. Look at how a tiny flaw in the implementation of RC4 in wireless networking makes the system crackable in linear time!
The big problem with a one-time pad is that you're left with keys the size of whatever message you intend to send. And since a real one-time pad CAN'T be generated deterministically (thus its security) the pad must be somehow shared between the two parties.
At best, they have re-invented the symmetric cipher- or something that approaches its intended function. Of course, never, ever trust a new cipher without a good long time of testing and proper cryptoanalysis.
Whoever is doing this is very, very likely selling snake oil. My suggestion is to pick up a copy of GPG, configure to use AES-256/3072 bit public keys and be happy.
-Ouija- poke 53280,11:poke 53281,12
> First off, the OTP is completely 100% unbreakable [in theory]. Even with infinite time an OTP is unbreakable.
Wrong. Given infinite time, a monkey will eventually bang out the contents of the OTP. Nothing is unbreakable given infinite time. Period.
got his story rejected months ago. Only to have it now appear. heh.
That the editorial staff are morons (and insist on demonstrating that again and again) doesn't help matters much either, but you aren't so snide about that.
At least when Slashdot was free we knew we only get what we paid for. Now that you are a fully commercial entity, you ought to remember "the customer is always right."
"It's not a war on drugs, it's a war on personal freedom. Keep that in mind at all times." Bill Hicks
Tristrata was a company that came around 2 years ago with broad claims to have invented a new type of cryptographic protocols as strong as one time pad with all sorts of new nifty super duper algorithms. Gobs and gobs of money were dumped onto the company. And when the "revolutionary" system was opened to public scrutiny, it was immediately exposed as just a big heap of obfuscation over run-of-the-mill cryptography. Tristrata went under in early 2001, if I remember well...
:
This article (and company) smells very strongly of Tristrata-ism. A comment about the one time pad algorithm is revealing:
The complexity of each random page in the "book" makes it nearly impossible to crack the code. And even if someone intercepts the message, there's no pattern to it that might help them decode the entire transmission.
Duh! The randomness of a one-time pad is not complex, it's random. It's not "nearly
impossible to crack". A one-time pad is impossible to crack by interception of the cypher text. Period.
Another one is fairly good too
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,[...]
Yeah, right, whatever. And what's this "secure process known only to Prescient", please, pretty please ? A courrier running around with floppy disks, may be?
I'm not going to bash those guys any longer. I can't exclude they have a few good ideas here and there. I don't know. But the article itself is pure puffery. A new one-time-padish cypher without a one-time pad is about as likely as perpetual motion.
Sig: You can't see my $0.02. They're one-time pad encrypted.
I'm going to start posting this every time it happens.
It's not all of Slashdot. It's just this Timothy fellah. Look at the poster of the article when you say to yourself "This is dumb. This shouldn't be here!" and I'll bet 9 times out of 10, Timothy posted it. He posts the stupidest, oldest, most untrue, FUD articles he can find. I think I'm going to fucking filter him.
So place the blame where blame is due.
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.
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
Ave Molech Setting
He'd be defrauding investors by skewing data about the company indirectly, and be sued by the SEC.
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.
It's only a one-time pad if you're using actual random data! If you're generating the data with some kind of formula, as these people are doing, it's just plain encryption, and if the company is calling it a "one-time pad" it qualifies as snake oil. If you're not exchanging as many true-random bits as you're encrypting, it's not a one-time pad. Anyone who thinks this company should be granted any credibility at all should go to counterpane.com and browse the monthly newletter archives for an hour or so.
Given infinite time, any, and I mean any, encryption can be broken.
Proof is that the probability of guessing the correct key increases as the length of time spent guessing increases. In other words, as time approaches infinity, the probability of guessing the correct key approaches one.
Any monkey given infinite time can bang out the duplicate of a OTP.
Yes, this is a matter of semantics, but if you are going to argue mathematics, you need to be exact.
boxeS.. whoever came up with the word boxen should be shot. Along with the fagots out there saying VAYKAY instead of VACATION
The right explanation is:
A one-time pad is secure because there is no way to figure out the keys without the codebook. Once you transmit the keys, this is no longer true.
E^2 is a block cipher, so the E^2-sec is just a ploy on the name of the block cipher.
FYI, E^2 was a AES submission by NTT Japan. Last I heard it had some security flaws but that doesn't discredit the argument.
Tom
Someday, I'll have a real sig.
At least when Slashdot was free we knew we only get what we paid for. Now that you are a fully commercial entity, you ought to remember "the customer is always right."
/. charge fees for user accounts? Nope. Are there extra fees for posting comments? Uh-uh.
How is Slashdot not free anymore? Is subscription mandatory? No. Does
Please explain yourself. The fact that Slashdot was bought-out by another company doesn't necessarily make it non-free all of the sudden.
Proud supporter of m o n o l i n u x
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.
"Time is an abstract concept devised by carbon-based lifeforms to monitor their ongoing decay." - Thundercleese
Looks like this is humor by obfuscation.
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.
when we're doing "it"
bwahahahaha
sorry, couln't help it. Slashdot needs some sister jokes.
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.
That argument applies to ALL encryption algorithms. In fact, skip the key step -- just guess the MESSAGE. The probability that you guessed the right message increases the longer you keep guessing !
The reason why this line of reasoning is junvenile is that there is no game show host who is going to ring the bell when you guess right. All messages are equally likely. If you guess "I am going to blow up your sandcastle with a firecracker", and then guess, "There is no message in this encryption I did it just to watch you waste your time", how do you know which one is right ? If you could show that one was more likely than the other, then that would be a weakness of the encryption.
But how do you know you have the right key? The point of OTP is that given any message M and any encrypted message E, there is some key K for which encrypting M with K gives E. So it is actually *not possible* to know what the original message was, unless there is only one message of that length in whatever language you are using. :)
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.
Is this the new club for editors to use over speech they don't like?
"Your comment is stupid and you don't pay us so leave"
"Your comment is a troll and you don't pay us so leave"
"You said something I dont like and you don't pay us so leave"
Whatever the merits of this code - by definition it ain't a one time pad!
-- SIGFPE
... they'll unveil a perpetual motion machine!
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
random data processed by ANY algorithm will not produce more random data. Like the old 7UP commercial said "never had it, never will".
kennethnghawthorne +at+ hotmail.com
....the way they get around the problem of distibuting the private symmetric key dictionary is by having everyone download a copy?
....
Engineers designed this?
"Lawyers are for sucks."
- Doug McKenzie
Bahahahahaha. Unbreakable my ass. They haven't done *anything*. All they have supplied is an encrypted exchange of PSEUDO-random keys. Break their exchange method, and it's worthless. Look for this in the next Cryptgram.
One-time pads are indeed unbreakable, but who cares? The problem with one time pads is two-fold. First, use them more than once and they become breakable (hence the name). Second, due to the first limitation, both parties have to have a large number of synched one-time random number pads, know what order to use them, and here's the real catch, make sure they are somehow 100% secure from prying eyes. Any of these fail, and your messages become transparent. They are great for folks that have to send occasional messages to a secure site, but for everyday use they are logistically a pain in the butt.
But of course, in the infosphere that is slashdot, the true one-pad story is two stories below this one: Practical Quantum Cryptography. Vastly oversimplifying things, QC is a secure, tamper-proof way of providing two (theoretically) random people a way to exchange secure one-tame pads.
What were you expecting?
>> First off, the OTP is completely 100% unbreakable [in theory]. Even with infinite time an OTP is unbreakable.
> Wrong. Given infinite time, a monkey will eventually bang out the contents of the OTP. Nothing is unbreakable given infinite time. Period.
I hope this response will remove the impressive sentence "Period." from your vocabulary for a long, long time. Or maybe it means what it appears to mean: I'm so sure of myself I don't need to think.
The deal with OTP is that the number of possible keys is exactly equal to the number of possible messages. If you try all the keys, you get every possible message. It doesn't matter which message you start with. If you try all the keys you get all the possible messages. Is that progress?
In fact, with OTP the set of all keys is identical to the set of all messages (for a given bit length). By your definition of "break" you don't actually need to capture the encrypted message. The decrypted message is already in your keys file!
There is no way to know when a key you tried produced the correct output. Every output is produced by some key. Every output that is even vaguely plausible is in there. Every output entirely is in there somewhere.
With a roomful of monkeys I can break every message ever written. With an infinite amount of time they'll type out everything ever encrypted. I don't even need the original messages. Cool.
You should write a book: interception made easy. Or maybe you should just dig it out of your keys file. It'll save you the effort of putting your own words together in sensible patterns.
What's up with all the cypher stories lately? Is next weeks Cringley gonna be about the future of cryptography or something?
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
http://www.prescient.net/pdf/e2Sec.pdf
it reads "Proprietary and Confidential". Plus the pdf doceument security reports 40-bit RC4!
If that's their idea of security.... Forget It
Artificial intelligence is the study of how to make real computers act like the ones in the movies.
To anyone who thinks that this is somehow a good system I have two links for you:
s nakeoil
l -faq.html
http://www.counterpane.com/crypto-gram-9902.html#
http://www.interhack.net/people/cmcurtin/snake-oi
Read them and weep at the BS.
If you don't like it here, leave.
This type of attitude is fine for CNN or the New York Times. Either I like them or I don't. Take it or leave it, but don't complain.
But I've always thought of
Thus, our opinions about the content quality should matter.
Your dozens of pageviews per day only cost more money for Slashdot, and the fact that you don't subscribe doesn't help matters.
If the
And isn't there something wrong with an editor discussing, in public, a user's viewing habits and whether or not the user is subscribed? Seems to me there ought to be some privacy issue here.
This product certainly sounds like snake oil (does "a secure process known only to Prescient" inspire any trust?). However one-time pads could become practical using Quantum Key Distributions (mentioned in an earler /. story). QKD is a method of transmitting data in such a way that it is possible to determine whether the data has been intercepted (using the Uncertainty Principle) - if the key has been intercepted, simply throw it away and pick a new one.
AFAIK the problem with QKD at present (apart from distance) is that it is very slow; it's good for public key systems that only need a few hundred or thousand bits, but with a one-time pad cipher your key has to be the same length as the message.
in part, at least:
"This is number is exchanged with the server through a secure process known only to Prescient,"
How much do you want to bet this shows up as Cryptogram's snakeoil this month? And how much do you want to bet that it will be broken within six months?
Well, the poster isn't calling it a one-time pad. Just says mixing it in like a one-time pad. Perhaps the poster meant to imply that this algorithm could do something similar to what the article claimed was happening. I think the poster clearly knows that this stuff is not the same. They were probablyl posting as fast as they could to get first post.
Obvously they either forgot to run the conversation through their crypto team, or their crypto team needs quite a bit more schooling.
//TODO: Think of witty sig statement
RSA has been doing this for a long time.
If you use Linux, please help development of Autopac
karma whole, maybe. Mod him down then.
disrespectful
Check out the dictionary definition of slave, especially entry two:
(www.m-w.com)
Main Entry: slave
Pronunciation: 'slAv
Function: noun
Etymology: Middle English sclave, from Old French or Medieval Latin; Old F
rench esclave, from Medieval Latin sclavus, from Sclavus Slavic; from the frequ
ent enslavement of Slavs in central Europe
Date: 14th century
1 : a person held in servitude as the chattel of another
2 : one that is completely subservient to a dominating influence
3 : a device (as the printer of a computer) that is directly responsive to another
4 : DRUDGE, TOILER
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.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
So what you are saying is that the pattern inherent in symmetrical encryption is the dead giveaway for knowing when you break the encryption.
Unfortunately, you are forgetting the main piece of the puzzle needed to break any encryption. You need to know something about the message. Either you know the cipher, the nature of the message, or something that tells you the message is correct. Even OTP has a cipher formula, it could be complex or as simple as a XOR b = c. Assuming your cipher is a XOR b, we learn your message is a repeating character. Just an example.
Again semantics. Just because something is possible does not make it probable. It is "possible" to crack OTP. What makes it not "probable" is what you said in your post.
But there is another fundamental security flaw I haven't seen mentioned yet. That is that by definition there is no authentication possible with this architecture, meaning that the whole protocol is by definition exposed to a man-in-the-middle attack.
Let me explain. The article explains that there is no pre-setup required, because the encryption client is downloaded from the server when you start the connection. So how do you know that you got the authentic client? The answer is that you don't. Even if the (genuine) client program contains a server certificate and a signature of itself using the server's private key that can be verified against the cert, this does you no good if the client has to be self-certifying.
Here's how the attack works: the attacker sits between the client and the server, intercepting all the traffic that goes between them (well designed protocols such as SSL take specific steps to deal with this kind of attack, btw). The client says "give me the client program" and the attacker passes along the request. The server downloads it, keeps the program and passes along to the client a bogus "encryption" client program that claims to be the real thing but doesn't actually do any encryption. The client and server now both exchange information, via the attacker, who is actually doing all the encryption and decryption, collecting all the traffic and neither the server nor client are any the wiser.
This, by the way, is really basic cyptographic protocol stuff. You'd be much better off using SSL.
I'd be interested to know what the tech to management/pr ratio looks like for this company.
Curious about how fly by night they are? I know I am. I couldn't find them on USPTO or Strategis.
The actual name of the company is "Prescient International, Inc." - which is probably owned by an LLC. Here's an interesting google search based on that.
Interesting stuff. Is this the same company running out of a PO box in NC? Do they ever decide what their company actually does? Oh, and the last item in that search - a press release submitted December 19, 2001 describing the other product.
They must have an enormous number of people on their team. Three month turn around between reinventing RDMS and solving the world's encryption needs. Amazing!
--ipsuid
It appears Ockham lost his razor and grew a beard.
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
This 'secure process' is the weak link in this lame security scheme. Break that and you can generate your own "one-time pads" (sic). Sounds like complete crap to me.
http://hcsoftware.sourceforge.net/HardEncrypt/Hard Encrypt.html
great program, open source, extremeley secure.
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.)
In principle it is possible to do a brute force attack like that, and it will produce a correct decryption. But it will also produce many incorrect outputs, and it will give you no information about which output is the correct one. So you still won't know the plaintext for the message.
If you restrict to trying one-time pad, the output will be every string of bits with the same length as the input. I think it's fair to say that by generating this list you haven't decrypted the message, since you could generate the same string of candidate outputs by exhaustive enumeration, without referring to the cyphertext at all.
http://www.prescient.net/Solutions_e2Sec.htm
They also have a technical whitepaper about e2sec on this page which has a mathematical proof and a challenge to break their encryption. I'm no mathematician but the proof is not as specific as I wanted it to be. Can some mathematicians analyze this proof and post some comments if possible.
One time pads are secure based on the key generator being totally random, the key remaining secret, and never reused.
It is secure because without having the random key, if you used all possible keys you would get all possible outputs. IE not only would you get the secret message, you would get the gettysburg address, your shopping list, grandma's favorite cookie recipe, a private message from god to you, and an alphabetical list of all the killers involved in the JFK assasination.
Any key exchange involved would be as secure as the mechanism to exchange the keys. It actually sounds like there is a short key used to generate a long key, and that attacking the key generator is going to be the way to break the cypher.
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" :-).
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.
Infuriate left and right
"We're 100-per-cent confident in our technology," Mr. Kassam said.
Well, then, they shouldn't have any problem posting a REALLY, BIG bond to cover against any breakage of their product, shouldn't they?...
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 are long sequences of random numbers.
Block ciphers are bijections between Z_2^p and Z_2^p, where p is the block size.
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.
Exactly.. it all comes back to having to exchange a new polynomial or what have you for each transaction.. which is no better than a one time pad.
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:
"Make it ten--I am only a poor corrupt official."
--Captain Louis Renault (Claude Rains), Casablanca
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.
Gentlemen, you can't fight in here, this is the War Room!
ok, IHBT. so what? everyone is drunk and fool from time to time (it is 1am locally)
Did you read it? "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." This isn't a "National Enquirer" story, it's an "Alerting you to a lying company" story.
I, too, hate that term with a passion. I just took my 4 remaining mod points and hunted down 4 posts using that word and slapped them.
This is not a one time pad. A really secure one time pad has the following properties:
1) It is never transmitted in the clear, shrouded or not. (The fact that this thing transmits a program which builds the key, just means that cracking it will boil down to building a virtual machine to execute the given program. Just reverse engineer the virtual machine that performs the execution on the client side.)
2) A one-time pad must be as long as the message (and be a cryptographically soundly generated random number -- no computer language in existence implements a cryptographically secure pseduo-random number generator.) In many cases 10K is way too small. RSA keys of 128bits or so don't have the same cryptographic properties as a one-time pad -- comparing the security by comparing the bit lengths is inappropriate (OTPs have to be arbitrarily long.)
--
OTPs must be used at most once. So this is not practical in usual circumstances, since a new key must be transmitted along with every message anyway. Thing like AES is far more efficient since only one (much smaller) key is required, and can be safely used for arbitrarily long messages.
Other problems -- this also doesn't deal with server interloping.
I really think this is some serious snake oil.
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*
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
The thing described here is not unbreakable. The random bit generator could be co-opted. The polynomial function could be guessed or even deduced.
(To make sure it's really from HEMOS, just look at the parent post, which had been moderated into oblivion). 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.
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.
When in doubt, have a man come through a door with a gun in his hand.
Not only that, but a one-time pad needs to be as long as the communication that it's encrypting, in order to be theoretically 100% secure. So the server would have to be equipped with as much random data as all encrypted communication that's going to take place. Nonsense. I can use DES in Output Feedback mode, generating "random" numbers" based on a single 64-bit key and call it a one-time pad!
I know the Washington - Moskow hotline uses a(real :-) one-time pad, probably messages to nuclear subs also.
Hmm...
Exhange an initial secret through another protocol, use this secret to generate a an never-ending stream of pseudo-random bits, and use this stream as a one-time pad...
Yep, we've already got this algorithm.
You have to make sure both parties start to read the random stream at the same start offset. Otherwise; the party that is supposed to see unencrypted data will not.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
This isn't one time pad at all. This is just encryption with a huge key, and might not even be more secure at all that current standards(except for the key size). The only way one time pad is REALLY secure is if the key is at least as large as the message, and most importantly, is absolutely uninterceptible. If someone with a packet sniffer could read the message unencrypted, they could also intercept the encrypted key, decrypt it, and with the key, just XOR the other data. All the security relies on the encrytion of the key. So really, this is just whatever encryption is used on the key, not one time pad.
heh that was good... we need more 'statistics' posts here...
I was thinking more +1, offtopic, asshole.
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."
Wow.
This is staggering...
If I were TeX... I'd being saying:
Overfull crapbox... badness=10000
The product mentioned in the story is clearly snake oil
Several Slashizens jump all over it, authoritatively "pointing out the errors" and writing in the tone of someone who knows what they're talking about.
Several more Slashizens harshly criticise the initial critics for their incorrect 'analysis' and then VERY authoritatively give us their *expert* opinion. The vast majority of these posts are as ill-informed as the ones above.
Heres the thing kids: Cryptography == Mathematics. Yup. Really. I know you coded up a ROT-13 "cipher" in Java for your tradeschool programming 101 class.. but guess what? That doesn't quite make you a cryptographer.
Mathematics is a VERY exact science. What seems like a tiny error to the casual observer is downright offensive to a trained mathematician and just plain wrong, under any circumstances.
Now, lets look at the facts, shall we? How many of you arrogant, self-righteous jackasses that jumped all over the original set of posters have an advanced degree in mathematics? For arguement, lets say at least an MSc. Preferably a Ph.D., but we'll be generous.
Okay, good. Now... of those remaining with their hands raised... how many have studied number theory and abstract algebra in detail? By detail, I mean you'd be comfortable writing a comprehensive exam on the topic. Not an expert, but passingly familiar with key theorems and proof techniques.
Now, of those left... how many have studied the application of these things to cryptography?
How many have attempted to break a real cryptosystem in a serious way? (no Cleetus... the junior-jumble in the paper doesn't count).
If you can answer yes to all of the above, bravo. +5 Informative for you.
If not, where the **** do you get off acting all preachy and "setting us morons on Slashdot straight" on crypto? If you actually REALLY knew *anything* serious about crypto... you'd know HOW VERY LITTLE you actually know. I'll bet dollars to donuts that almost every single self-righteous blowhole poster here hasn't done serious mathematics since their required courses in college.
OH.. but you've *read* lots of books on crypto, so you MUST be an expert. I mean, hey, who needs this silly "math" stuff... You're too smart for that.
The overall content of 96% of the posts in this thread make my head spin. It is so mind-bogglingly ignorant... and whats more... the posters not only don't realize their own ignorance... they think they're experts! Look at yourselves people... you ARE the people who end up in companies like the one in the article.
My profound apologies to the 4% of you who *don't* have your head shoved so far up your rectum that you are clearly self-asphyxiating.
If you can truly do the equivalent of getting a one-time pad of arbitrary length between client and server without sending (most of) it, why not take the next logical step and send all of your communications this way. That way, you don't even need a connection between the two endpoints, and you've got infinite bandwidth between them.
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.
slashdot!=valid HTML
In utmost confidence here is a part of the top secret output of a military random number generator:
3 3 3 3 3 3 2 3 3 3 3 3 3 3 3 3
Hemos is user #2. If the post isn't from user #2, it's not Hemos. (hint, it's not from user #2)
Somehow I don't think Hemos would be the 569,506th member of his own site.
slashdot!=valid HTML
-Robert Coveyou
And where are the getting these random numbers?
sounds like pre-shared keys. But using somthing other than IKE.
Where can I get some programs to play around with One-time Pad encryption? I would need it to generate the pad and xor the file too.
I didn't use the preview button, so get over it!!!!
Mike
I have a room full of monkeys with typewriters! You just need to feed them and clean the floor once in a while, but you'll get 100% random data, guaranteed!
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
Send mail here if you want to reach me.
But it's worse than that: whatever this "set of equations" is, its effectively a pseudorandom number generator. There do exist cryptographically strong random number generators, but they are just as difficult to compute as a standard strong encryption, so this scheme reduces under this condition to being a standard encryption with a slightly modified key exchange process. (They're exchanging a whole equation, rather than just the key parts.) So it's neither more efficient in encryption speed, nor more effective in terms of difficulty to break, than the equivalent encryption scheme.
But wait! There's more! If the PRNG is not cryptographically strong, then the encryption won't be very strong either, as there are well-known ways of decrypting a ciphertext encrypted using weak PRNGs. (There is a very close relationship between a PNRG and an encryption algorithm that guarantees this will work.)
So, it clearly belongs in Schneier's "snake oil" section.
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.
I like dots....
....
However, when on the same Anger rampage you tend to understand the word fuck better. Fuck is an adjective, adverb, verb, noun,
I doubt there are other words that are quite so versitile.
Stream ciphers are a symmetric encryption scheme which try to emulate a one-time pad by generating random bits given a certain key.
The _only_ difference with these people's algorithm and stream ciphers is that the "equations" used to generate the random bitstream on stream ciphers are open, and have been tested by a large community of cryptanalists. In the case of this new scheme, only a handful of people BELIEVE that their equations are unbreakable.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
How long would it take to reverse engineer the "program"? The whole process? Ok, bets are running and I say 12 days.
--Drake 2c
The so-called technical white paper was one of the worst I've seen in ages.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
One-time pads work great. The question is, what's the point.
For every message, a different one-time pad must be created and secretly exchanged. Hm.... why doesn't the party just give the message to the other, unencrypted and secretly, in the first place? Nothing is really accomplished by using this encryption.
There are, of course, some rare incidents where secure means of exchange are not available at the time of the message, but were before.
company be Snake Oil Merchants Inc? If not, they should really consider changing the name since what they are selling is pure 100% Grade A snake oil.
It's possible that these "Prescient International" are really just uneducated morons, but being cynical as I am, I would rather believe that this is an attempt by another sleazy business to get investment from gullible VCs.
For generating random data from a computer, most say it CANT be done. However, the way I understand it, true noise is random, right? Well, cant you play something through a sound card (and with a loopback cable to the mic) record at the same time?
Usually you see that the sound card has "16 bits of resolution" bla bla.... In actuality, PC's generate quite a bit of noise on the pci bus, so that you get 12 bits of resolution with 4 bits of static. You just dont know what 4 bits are bad.
My idea is to use a sound card D/A converter and use the static as random data. Would this work? Why or why not?
We know all PRNGs are periodic, and this is probably based on some variation of a LFSR. Given known methods to attack LFSRs and discover the internal state require a large enough sample size, we know
1. This is totally insecure for transfers larger than the PRNG period (XOR differential attack)
2. For data with known N-bit patterns, (like headers/trailers) we can remove the pattern and gain access to N-bits of the LFSR output.
3. CBC-mode encryption will not provide any more security, since the pad computation is an easily computable group operation (XOR is a group - DES is not, which is why 3-des and CBC work well). It does mean we can't extract trailer patterns unless the packet is short and redundant, however.
4. Since we most likely extract several dozen sequential bits of the LFSR, determining the LFSR internal state becomes much easier, especially as packet length increases. If an entire HTTP session uses a single key exchange, I'd say there is probably enough redundant data to crack the LFSR.
That said, with some simple enhancements, these obvious flaws are no longer present -
1) As part of the negotiated exchange, a random squawking size is agreed upon. Each packet is prefaced by a truly random squawk. The squawk size is computed to lie within bounds such that it can sufficiently mask bit patterns in the data.
2) The squawk + packet is compressed before applying the pad. Now the known patterns are effectively masked.
However, at this point, we've destroyed the usefullness of the algorithm, which was the fact that it required very little CPU power.
I'd guess that even with squawking, finding the pattern data is going to be too easy until compression, unless the squawk is so large that it dwarves the packet size, in which case the wire transmission is horribly inefficient.
So in all, a novel idea, which given more work could perhaps be useful, but in the form described right now, totally useless. And I can't see how it would take more than 4 hours to code and debug, let alone 4 years.
Intelligently generated true One Time Pads and crypto with them is uncrackable, that's for shure. But this simply doesn't qualify for reasons that allready have been posted here.
:-)
Leaving that aside, OTP Crypto actually IS the safe Cryptomechanisim of the future! Nobody knows when someone will find a prime number algorithm or how far for instance the NSA has gotten near to one. Clifford Stoll mentioned something like that in 'The Cuckoos Egg' quite some time ago that hints in this direction.
Anyhow, Computers are getting faster and 'bigger', and brute force attacks can bring down a specific cryptomessage of email-length in less than 2 months nowadays, given you've got the hardware or the appropriate distributed computing software. But also mass storage is getting cheaper. With DVD-R just around the corner to consumer market it would be no problem for me to exchange a handfull of OTP disks with my friends that would last a lifetimes worth of crypted email. There only problem here (as with asymmetric crypto) is keeping track of the keys and the parts that where used allready.
A Software to manage this actually is a GPL project I have in mind for quite a time now...mmmmh... anyone interessted in getting it on?
Coming to think of it: That would actually also cut down the fuss of constant revoking and updating of public keys.
The downside of all this is of course that OTPs can't be public. Smart, ain't I ?
We suffer more in our imagination than in reality. - Seneca
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.
-no broken link
One: It blows my mind that we (the Slashdot community) have so many extremely-knowledgable people in our ranks. Some of this discussion is so far over my head, it's scary. (But I'm just a mechanincal engineer, not a computer scientist.)
Two: It seems to me that several people established how stupid this company was early on. Wouldn't it be more interesting to talk about why they would try to do such a thing? Is it to gather venture capital? What are the backgrounds of the people involved? Do they have a history of grift?
My point is that this is obviously a sham. What's the story behind the story?
dk
Acts 17:28, "For in Him we live, and move, and have our being."
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.
I don't have an valid answer except but to point out that in practice, source validation can be achieved in most common scenarios _of_today_
I guess...
didn't the various generations of the Enigma cipher use this concept?
Using the same value to XOR each letter of the plaintext with doesn't even qualify as 'encryption'. It's just a wacky version of ACSII.
It really amazes me the number of people we have wandering around claim that 'even OTPs are breakable'. No, they aren't, you're just embarassing yourself to claim they are.
If corporations are people, aren't stockholders guilty of slavery?
'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.'
Isn't this still vulnerable to man-in-the-middle? If you can intercept communication between client and server you can get the pads. Sounds to me like it's only the fact that the process for transfer is obscure that prevents this. Security by obscurity.
' Ore stabit fortis a fine placet ore stat '
- found on a park bench
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. :)
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
Play with my webcams and lights here
For those of you that don't want to read the whole article, I'll spoil it for you.
"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.
Proves one of two things, Mr Kassam (from the company this piece is about) either does not understand tha product, or the product is not equivalent to a OTP. It's a very simple proof.
The data can be reconstructed using less data than is in the pad itself
The pad is not wholly entropic
The resulting system is not in any way shape or form a OTP.
Of course I haven't presented the proof with any formality to it, but I don't think it needs it.
So from this we can conclude one of two things.
1) They don't know what they are doing
2) They lack a fundamental understanding of the most basic computer science, which of course is the same as "They don't know what they are doing"
So they don't know what they are doing, and I wouldn't trust them to protect my email address (which I consider public knowledge), let alone anything important.
The biggest benefit is that it should be more difficult to break because crackers don't know enough about the algorithm. The biggest drawback (assuming the algorithm really is secure) is that scientific trust would be difficult to gain.
Regarding offering many locked 'boxes', many cryptographers are working on security with 'unlocked boxes'. There have been algorithms based on 'chaff', or garbage infomration included with legitimate information, that are relativly secure. Proposals have included combining multiple message sources and segmenting all the messages into similar (very small) pieces and attaching a public-key-signed signature to each of them. The messages are never actually encrypted, but they cannot be recovered in order without being able to open the signatures to re-assemble them.
Getting back on the topic of their routine, it is a bad algorithm (a bogus OTP), and they have already taken a beating on /. about it.
//TODO: Think of witty sig statement
While that seems possible, that's near impossible to do in practice. About the only way to get algorithms tested is to hand them out to the public. Cryptologists don't personally care whether or not your supersekret code is 'good', it has to get though several levels of 'testing' before the top people will even look at it. They rely on people 'below' them (Slashdot, crypto newsgroups, etc) to filter out all the idiotic schemes. (Like this one, it didn't even make it past /., which is really sad.)
If you have a new algorithm, and aren't a real cryptologist, you has almost no chances of having a real one look at it until a lot of random people have looked at it and say 'Well, I don't see anything wrong with it'. You can't just walk up and order them to test it without paying them a lot of money.
Not to mention you shouldn't be relying on the algorithm being secret at all, as the very first publicly sold copy will even up being reverse engineered and everyone will know the algorithm anyway.
If corporations are people, aren't stockholders guilty of slavery?