Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

One-Time Pad Encryption With No Pad? 415

Posted by timothy from the strength-of-weakest-link dept.
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.
This discussion has been archived. No new comments can be posted.

One-Time Pad Encryption With No Pad? More

One-Time Pad Encryption With No Pad?

Comments Filter:
  • 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!
    • 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.

  • I doubt it (Score:4, Insightful)

    by Waffle Iron ( 339739 ) on Thursday March 28, 2002 @04:24PM (#3243954)
    ... 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.

    • 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 (Score:2, Insightful)

    by happyhippy ( 526970 )
    "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.
    • "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 (Score:3, Informative)

    by Hemos (editor) ( 569506 ) on Thursday March 28, 2002 @04:26PM (#3243968) Homepage
    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 [aspheute.com]

    ---
    Partner Linux Site [monolinux.com]

  • I think we've been here (Score:5, Interesting)

    by fm6 ( 162816 ) on Thursday March 28, 2002 @04:26PM (#3243975) Homepage Journal
    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..."

    • 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!

    • Classic Snake Oil with = ~20-bit key (Score:5, Insightful)

      by billstewart ( 78916 ) on Friday March 29, 2002 @12:04AM (#3246371) Journal
      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.
      • 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.

  • Now I can win $100,000! (Score:3, Funny)

    by nsample ( 261457 ) <nsample.stanford@edu> on Thursday March 28, 2002 @04:27PM (#3243977) Homepage


    I will use the secret powers of generating reproducable one-time pads to solve the equally overstated Bodacian challenge [virtual-media.com]!


    The world will be all mine, Pinky!

  • nonsense (Score:5, Insightful)

    by egomaniac ( 105476 ) on Thursday March 28, 2002 @04:27PM (#3243982) Homepage
    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!"
    • "As long as a program is producing the keys, they will exist in a particular sequence. "

      why?

      • Re:nonsense (Score:4, Insightful)

        by MindStalker ( 22827 ) <mindstalker@gmai ... com minus distro> on Thursday March 28, 2002 @04:58PM (#3244241) Journal
        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 (Score:4, Informative)

        by curunir ( 98273 ) on Thursday March 28, 2002 @05:05PM (#3244272) Homepage Journal
        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 (Score:2, Interesting)

          by dracken ( 453199 )
          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
    • 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:nonsense (Score:3, Informative)

      by rm -rf /etc/* ( 20237 )

      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 :)

  • Hrmm... (Score:3, Funny)

    by Arcanix ( 140337 ) on Thursday March 28, 2002 @04:27PM (#3243983)
    So essentially they send the keys to the unbreakable cipher using a breakable cipher, sounds completely secure to me.

  • Not a One Time Pad.... (Score:2, Informative)

    by alanh ( 29068 )
    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 (Score:3, Interesting)

    by westfirst ( 222247 ) on Thursday March 28, 2002 @04:27PM (#3243989)

    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.
  • 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.

  • Keyspace (Score:3, Interesting)

    by Rupert ( 28001 ) on Thursday March 28, 2002 @04:30PM (#3244018) Homepage Journal
    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.
  • 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).

    • 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...

  • WEBSITE LINK (Score:5, Informative)

    by drDugan ( 219551 ) on Thursday March 28, 2002 @04:31PM (#3244027) Homepage

    finding their website was non trivial on google

    its here

    http://www.prescient.net/ [prescient.net]

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

  • *scoffs* 'unbreakable' encryption (Score:4, Interesting)

    by merlin_jim ( 302773 ) <James DOT McCrac ... ratapult DOT com> on Thursday March 28, 2002 @04:33PM (#3244051)
    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 (Score:5, Insightful)

      by Citizen of Earth ( 569446 ) on Thursday March 28, 2002 @05:23PM (#3244384)
      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.
    • "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.

    • 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.

    • Wrong. (Score:5, Informative)

      by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday March 28, 2002 @05:48PM (#3244561)
      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.)

  • Author should be ashamed (Score:3, Insightful)

    by tomstdenis ( 446163 ) <tomstdenis&gmail,com> on Thursday March 28, 2002 @04:34PM (#3244062) Homepage
    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
  • 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.

  • dubious (Score:2)

    by zook ( 34771 )
    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.

  • reminds me of some old Crypto-Grams in which Bruce Schneier [google.com] blasted [counterpane.com] this concept out of the sky. How is this different? Everyone claims to be unbreakable [oracle.com] until they're not.

  • They improve the security even further, by using their patent-pending universal 16:1 compressor (in two passes, for 256:1 compression) on the plaintext before encrypting it.

  • "Unbreakable" is to "encryption", as... (Score:5, Funny)

    by volpe ( 58112 ) on Thursday March 28, 2002 @04:37PM (#3244088)
    ..."unsinkable" is to "ship"
    • Eh, except that some encryption is unbreakable. See HardEncrypt [sourceforge.net], for example.
      • 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 [uscg.mil], 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.

      • 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.

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

    • 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;
      }

  • Take a secure method and add multiple weaknesses.. (Score:3, Insightful)

    by Jelloman ( 69747 ) on Thursday March 28, 2002 @04:39PM (#3244104)
    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.

    • 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.

  • Very likely just rubbish (Score:3, Insightful)

    by tempmpi ( 233132 ) on Thursday March 28, 2002 @04:41PM (#3244118)
    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.
  • (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.

  • 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.

  • 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

  • "One time pad"+modifications ISN'T A ONE TIME PAD (Score:3, Insightful)

    by IvyMike ( 178408 ) on Thursday March 28, 2002 @05:10PM (#3244300)

    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.

  • ...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!

  • RSA has been doing this for a long time.

  • Flat out lies (Score:3, Insightful)

    by Alsee ( 515537 ) on Thursday March 28, 2002 @05:28PM (#3244434) Homepage
    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.

    -
  • 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" :-).

Slashdot Top Deals

This is now. Later is later.

Close