Encryption Software

Discussion in 'privacy technology' started by dallen, Sep 18, 2005.

Thread Status:
Not open for further replies.
  1. heyUthere

    heyUthere Registered Member

    Sep 30, 2005
    I do not know if you guys know about TOR http://tor.eff.org/overview.html
    Using Tor protects you against a common form of Internet surveillance known as "traffic analysis." Traffic analysis can be used to infer who is talking to whom over a public network. Knowing the source and destination of your Internet traffic allows others to track your behavior and interests. It can even threaten your job and physical safety by revealing who and where you are. You can inadvertently reveal your national origin and professional affiliation to anyone observing the network, even if the connection is encrypted.

    check it out!
  2. Paranoid2000

    Paranoid2000 Registered Member

    May 2, 2004
    North West, United Kingdom
    Tor has been discussed in many other threads here - it does cover a different area though, providing online anonymity (using both multiple levels of encryption plus routing traffic via proxies) rather than secure storage of private data on disk. It is therefore not really applicable to this thread.

    It is also worth noting that while Tor can make traffic analysis harder, its main benefit is encrypting your connection in the first place. Without this, your ISP can easily view all your online activities (and many are now required to log them under increasingly draconian data retention rules).
  3. Deven

    Deven Guest


    I suspect the author got distracted by other things and forgot to renew the domain name.

    Take a look at this URL for a working copy of the old "rubberhose.org" site, I believe it is the author's site, just under another domain name, but it may have actually been the same server:

  4. StevieO

    StevieO Guest

    Hi Deven,

    Thanks for the info and link, which does work for me !

    Have you actually tried it or know anyone that has, and if so how what do You/They think of it ?

  5. StevieO

    StevieO Guest

    I found this on the RubberHose link that Deven gave me.

    . . .


    Rubberhose places extreme demands on random number generators and
    ciphers. It is not enough for a generated stream to be merely
    irreversible. There must be no computationally feasible way to
    detect ANY (statistically significant) correlation between values
    in the stream.



    . . .

    Lots of other very useful and interesting info over there too. Very indepth and mostly over my head, but i learnt things anyway !

  6. Deven

    Deven Guest

    Glad it worked for you. While much of the site is on archive.org, that doesn't have the actual download, while this site does. Like I said, I suspect this was either a mirror or maybe the actual original site via a different URL...
    No, I haven't tried it yet, but I thought it looked very interesting, especially that you can have multiple layers of hidden data. I thought it would be interesting to use it on a CD-ROM, since you wouldn't have to worry about clobbering the hidden data if you're using read-only media...

  7. Rilla927

    Rilla927 Registered Member

    May 12, 2005
    Hi Jackson,

    I had the same question about DriveCrypt products. Why did they remove your link? I thought you were allowed to post links.

    I was going to post a link with my question to see what everybody thought. This really puzzles me!
  8. Alex5

    Alex5 Guest

    One Time Pads

    Over the years there were many stupid and/or dishonest "security experts" who claimed proven un-breakability of their products as One Time Pads while in fact providing products which substitute random key of One Time Pad with stream cipher. While such products are NOT One Time Pads and can claim nothing of it's proven un-breakability they did in many cases provide considerable security as stream ciphers.

    Now, this one is truly in a league of his own. He didn't substitute random key for cryptographically secure pseudo random number generator, or no. He advised people to use any other files as keys. Any MP3 or JPEG lying around will do, as long as attacker doesn't know which one was used.

    And it doesn't look like he's being dishonest. It looks like he actually knows absolutely nothing about cryptography.
  9. IamScared

    IamScared Guest

    A little observation. Twofish is broken. The best attack now is around O(2^52), against the theoretical O(2^256) brute force attack. There is a paper by Moriai and Yin, two japanese researchers called "Cryptoanalisys of TwoFish" that presents the technique.

    With respect to OTP, being myself a graduate student in cryptographic research.. OTPs are theoretical unbreakable, but their realization is extremely hard, because a lot of details have to be considered. Common users don't have any means to accomplish them in a real world scenario.

    Another point is that the algorithm AND THE IMPLEMENTATION has to be public, so that the community can test and evaluate the security offered by a cryptography product. Beautiful "textbook algorithms" can be totally insecure by a broken implementation. Example: RSA in ECB mode.

    So, why don't use well-known community-verified cryptographic primitives like AES or Blowfish? The keys can be protected furtherly by assymetric crypto algorithms, like RSA or ECC.

    OTP is a inadequate solution to a problem that has fairly good solutions.

    Good solutions are PGP, GPG (this is open-source and patent-free!) of the openssl command line utilities.

    I like GPG and use it in a daily manner.

    IamScared (or Diego Aranha, for the ones that like to attack arguments based on the anonymity of the poster :/)
  10. Arlen Cuss

    Arlen Cuss Guest

    Re: Rubberhose.org

    Yes, that's the orirginal author's site (Julian Assange). I suppose he has better things to do than pay for domains!
  11. Phleg

    Phleg Guest

    Or...not. The strength of encryption must be dependent upon the security of the key, and only the security of the key.

    If I encrypt a file that I want to remain secured, I'll use an encryption algorithm which uses both diffusion and confusion. Confusion is analogous to the XOR encryption being done; values in the plaintext being replaced by other values in the ciphertext. Diffusion, on the other hand, distributes the statistical information of a file amongst the length of a block.

    With both of these techniques together, even with the plaintext and ciphertext, one cannot discern the key.

    On the other hand, with XOR, knowing the plaintext, or even statistical information about the plaintext, renders the 'security' nearly useless, unless you're using a key with a length exactly as long as the plaintext. However, even in this case, you can still be vulnerable. Firstly, you have to store the key securely, which poses exactly the same problems as storing the original file securely. If you keep the key with you to make sure it's secure, you might as well just be carrying the file itself. Even worse, if you use the same key more than once, any sort of statistical information in your data (usually file headers, but often predictable parts of the actual contents, too) can lead to the entire key being broken trivially.

    This quote only indicates how inexperienced you are with true cryptography. This extra rigamarole is pointless, and I'll show you why. Let P be your plaintext, C be the resultant ciphertext, K_1 be your key, and K_2 be the key you encrypt both with. A "^" is the XOR operation.

    Your process starts off as the following:

    C = (K_2 ^ P) ^ (K_2 ^ K_1)

    Unfortunately for you, XOR is a commutative and associative operation. So really, all you're doing is this:

    C = (K_2 ^ P) ^ (K_2 ^ K_1)
    C = K_2 ^ P ^ K_2 ^ K_1
    C = P ^ K_1 ^ K_2 ^ K_2
    C = P ^ K_1 ^ (K_2 ^ K_2)

    It's trivial to note that any string XOR'd against itself is nothing but zeroes, and any string XOR'd against zeroes is itself, so finally we have:

    C = P ^ K_1 ^ (K_2 ^ K_2)
    C = P ^ K_1 ^ (0)
    C = P ^ K_1

    Welcome to futility, population: you. You've achieved nothing extra, but now you need to carry around and protect two keys the size of the file (well, technically you don't, but if you'd known that you wouldn't have done this in the first place).

    I do. Apparently, you don't.

    Because you don't come across random files in the wild that you need to decrypt. I will say it clearly: that file is probably very difficult to crack, for the explicit purpose that we didn't know (at the time) what type of file it was, any type of statistical information about it, and we have no information about the key generator he uses, and what its statistical properties are. And there's the trick: this type of security is great for protecting your pornography from your parents and kid sister, or for putting a random file on the web to "challenge" people to decrypt.

    However, in the real world, cryptanalysis doesn't work in quite the same way. Typically, one analyzes many ciphertexts in tandem, all generated with either the same key or the same algorithm. With an pseudo-OTP generator like the one presented in XorIt, virtually any type of attack will exploit the fact that he's likely using some form of cryptographically insecure random number generator: i.e., (a + bx) mod c, which is the most common one, or some form of the Mersenne Twister. Even with a more secure algorithm (I believe Blum Blub Shub was mentioned), many attacks still remain.

    There are very, very strict requirements on a One-Time Pad that must be in place for it to be cryptographically secure, and it is impossible for a deterministic computer to satisfy all of them. The others are excessively and pointlessly cumbersome.

    1) a truly random number generator
    2) secure key transmission and storage
    3) secure key disposal
    4) keys the length of each plaintext
    5) a unique key for each plaintext

    The first isn't as hard now, with Blum Blum Shub. However, there's no way to guarantee that it won't be possible in the near future to predict sequences from the algorithm, as it is a deterministic PRNG.

    The second criteria virtually eliminates doing anything over a network. If you transmit your key to someone digitally, you have completely invalidated any security that might have been had with this type of algorithm. If you find some way to transmit the key securely, you might as well have transmitted the original date over that same channel.

    The third criterion is extraordinarily difficult. Even after wiping your hard drive, data is quite often able to be retrieved. Deleting the file is simply not good enough. Overwriting it with alternating bit patterns is an improvement, but cumbersome, time-consuming, and still doesn't totally neutralize this means of attack. Like I said: great for your kid sister, bad for anything actually important.

    The fourth is in some ways the worst of the bunch. If you want to encrypt an ISO, for instance, you need a key around 700MB in length. Not only does this take significant time to create, but you also need to now keep TWO large pieces of data secure rather than one. Since the key to be kept secure is exactly the same length of the data, it might as well be the data itself.

    The fifth isn't difficult, but it requires that the person using the software know about this limitation. Also, it means that you double the storage space required for encrypting anything.

    So I ask you: why go through all this effort? Why use a product that doesn't publish its source code for peer review (often, the algorithm a commercial vendor uses is perfectly secure when used correctly, but is badly implemented; c.f., static initialization vectors in the RC4 for WEP), go through the extra hassle of carrying large, cumbersome keys, give up the ability to transfer your files over a network or otherwise share the information with select others, and uses a technique that is only (potentially!) secure given the most extreme constraints, especially when alternatives exist?

    And alternatives do exist. The recent AES algorithm (Rijndael) is fast, proven to be secure (the best cryptographers in the world have yet to break it, even with virtually their full attention on it for a decade), lets you re-use keys, has keys of a reasonable length (128-, 192-, or 256-bit), and is safe for transmission over a network or other insecure medium (the key can be encrypted with a public/private keypair and transmitted; this cannot be reasonably done for OTP, due to the massive size of the keys and the poor performance of all asymmetric algorithms).

    Furthermore, if OTP was so easy to implement securely, why does the cryptographic community spend so much time, effort, and money on creating new and complicated algorithms, when OTP has existed for decades? Why spend nearly a decade reviewing dozens of symmetric algorithms for the recent AES standard, analyzing every aspect of their security, searching for weaknesses? If OTP was truly the holy grail of encryption, why go through any of this? Because, frankly, it's not possible or practical to implement securely in computer hardware or software.
  12. Phleg

    Phleg Guest

    Oh, and therein lies the rub. If you're carrying around a DVD full of your various keys, and keep that secure, why not just keep the data on you in the first place? They're the same size, and they have the same security constraints. What do you gain?
  13. Andrew Glina

    Andrew Glina Registered Member

    Sep 22, 2005
    Hobart (Australia)
    I'm Back

    To Phleg

    Congratulations. You have just discovered what everyone else already knew; OTP encryption is generally not practical for securing large amounts of files. It is best used for message transfers. (It has been said several times even in this thread.)

    I hope you enjoyed writing that essay.
  14. Random User

    Random User Guest

    I've read through a most pages of this thread and it amazes me what a flamewar this has become. Why do some people, as I see it, of true cryptology knowledge, join this discussion?

    I've joined this discussion simply because of Bruce Schneier's newsletter which pointed me to this thread.

    I've noticed a few things:
    1. Andre Glina, the author of XorIt. Has a basic knowledge of cryptography.
    2. Andrew Glina advertises his creation.
    3. Most users in this thread look at his creation as snake oil.

    Q. Why is it snake oil?
    A. True world application is not feasable.

    (Q/A as the discussion goes, not my opinion which comes next.)

    True/False: In my opionion: True. It is snake oil.
    Why: Andrew Glina says XorIt is a one-time-pad and no more.
    For one-time-pads it is argued that one needs a TOTALLY random
    source. I argue this is not true for ALL applications of a one-time-pad.
    However it is also argue that for the INTENDED use of XorIt it it not
    feasable. Not feasable is not contradicting Andrew Glina's statement.
    Then we see to the "public": Does the "public" understand the basics of
    cryptology? In my experience: No. So, if the "public" thinks of this as
    the FINAL solution to hiding information, as Andrew Glina would like the
    "public" to think, the "public" will be mislead.
    Conclusion is that XorIt is "snake oil". (In my opinion).

    Snake Oil is per definition: (My own words/opinion)
    A remedy for an "illness", but does not provide, for ANY "buyer", the
    intended result.

    To this I have a few points to add:
    1. One who want's to sell (or is it freeware, w/w.o source, if so disregard this point) this kind of security that is very misleading to the uninitiated doesn't know what he/she does, is really dumb or businessmart.
    2. To create a encryption scheme is easy, but to create a SECURE encryption scheme is hard.
    3. If you have a knowledge of cryptology, do not take persons like Andrew Glina very seriously. However, when such persons tries to induce the "public" with "false" information make your argument and then leave when the person doesn't seem to understand what all your points are. You do not want to teach him/her since it is not in your interrest. You only want to prove him wrong. Well: YOU CAN'T. All this discussion leads to is more monetary loss for your employer when you discuss this at work. :)

    Andrew Glina "sells" a secure encryption program.
    What does this mean?
    Most opionion in this thread: secure=Secure.
    In Andrew Glinas opinion: secure=Proven Secure.
    The threads opinion on XorIt: Secure but not feasable.
    Andrew Glinas opinion on XorIt: Proven Secure.
    (Correct me if I'm wrong but this is what I've gathered from posts this far.)

    Andrew Glina seems to misunderstand some very important keywords:
    Proven Secure: Unbreakable in any way. Hacking, bruteforce, etc.
    Not feasable: Cannot work at all or might work under some certain circumstances.
    Secure: Something that is secure. Unless... (fill in your own explination).

    Final Q/A:

    A. Do I support Andrew Glinas statements?
    Q. No, He contradicts himself at numerous times and seems to have very little
    knowledge of cryptology.

    Q. Do I think Andrew Glinas' XorIt is good?
    A. No. It serves no purpose for the "average joe".

    Q. Does XorIt work as intended?
    A. Yes. It works as a one-time-pad and that was the intention.

    Q. Would I promote XorIt?
    A. No! See answer #2.

    Last words:
    If we look at MY definition of "snake oil" we see the words "for any buyer".
    This translates to:
    If a single buyer gets the result he/she thought he/she would get then this would not be "snake oil".
    This is only semantics and not of importance of this discussion/thread.


    (Yes I've read Bruce Schneier's work and many others too and yes I've been working In this field for so and so long but who cares! Can't we all just get along!? :))
  15. Random User

    Random User Guest

    Corrections to the last post:

    However it is also argue that for the INTENDED use of XorIt it it not feasable.
    should be:
    However I also argue that for the INTENDED use of XorIt it it not feasable.

    Proven Secure: Unbreakable in any way. Hacking, bruteforce, etc.
    should be:
    NOTHING. Since Andrew Glina seems to understand this concept, but does a false application of the statement.
    (Should have been: Proven Secure: Mathematically proven unbreakable.)

    I blame it on Cut'n'Paste. ;)

    Might be a few more mistakes but I'm on my last beer now so... be gentle. :)
  16. Andrew Glina

    Andrew Glina Registered Member

    Sep 22, 2005
    Hobart (Australia)

    Well you are entitled to your opinion "Random User", and since mine has been re-iterated several times to other anonymous users I will not debate you... much.

    The main point that I feel needs to be clarified is that you are wrong about the purpose of XorIt. It was not written for OTP at all. (Vernam is not the same as OTP.) As I say "XorIt is designed to use conventional XOR encryption on keys that are the same size as the file to be encrypted." No mention of OTP there at all. I only mention OTP with emphasis some of its needs, with further clarification in the ReadMe. It was actually written for a friend of mine for usage with a Blum Blum Shub pseudorandom number generator. Thus, by your definition, it is not "Snake Oil"! Don't worry, I am only joking. See it as "Snake Oil", "Frog Oil" or whatever you want. I am not trying to persuade you, or anyone, of anything. I just wanted to make that point.

    But please do not accuse me of being deceitful. I notified my users of the Bruce Schneier "review" and to the registered users I have offered refunds/exchanges. No one wanted one. If anything, this has made XorIt/CryptIt more popular!

    (Incidentally, what do you mean by "Andrew Glina advertises his creation"? I have not spent one cent on advertising for any of my programs. Putting it on my website hardly qualifies if that is what you mean.)
  17. schneier

    schneier Guest

    "A little observation. Twofish is broken. The best attack now is around O(2^52), against the theoretical O(2^256) brute force attack. There is a paper by Moriai and Yin, two japanese researchers called "Cryptoanalisys of TwoFish" that presents the technique."

    Twofish is not broken. The paper mentioned above does not contain a Twofish attack. It's a great piece of cryptanalysis, and there is the a distinguising attack against reduced-round Twofish that's the best out there. But there's no way to extend that attack to more rounds, and no way to convert the distinguishing attack into a key-recovery attack.

    Unfortunately, the paper is not on-line. I am working to get it on line. I will also post more about this in my blog.

Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.