Encryption Software

Can I join your discussion Devinco? Mine seems to be going nowhere.

 

Re: Why am I bothering?

Hi Andrew,

just some quotes from your webpage :-

Not a bad start...

So now you're saying that every symmetric encryption can easily be cracked/broken? Hmm maybe you know something that the rest of the world doesn't, if so quite a few people would be interested in your findings. Rinjdael broken? TwoFish broken? Interesting, especially since if a 128-bit symmetric algorithm cannot be "broken" and only bruteforced, its theoritically impossible to recover the plaintext/key. Regardless of how many computers you put to the job.

So now after putting down everyone else's implementation, lets see what your program can offer us. :-

Virtually unbreakable hey...

You tell people to use insecure "key files" to protect their plaintext files, just after saying that its virtually unbreakable? How is that possible? Your claim of "virtually unbreakable" might be true if you told them they would need a close to 100% random key data, but you don't. You should also mention that you don't provide the option to generate something which might come close to resembling random.

Saying that your program can be used to do OTP is like me saying Windows can be used to do OTP, provided you have the software to do it. You can't do OTP with just your program.

 

OTP

If the key file is unpredictible then the plaintext cannot be decrypted. There is no need for the file to be random. It just needs to seem random to the hacker.

I am not putting down anyones methods, I am just stating facts. The problem with using XorIt as directed is that you need to be able to transfer and store keys securely. That is a big problem. I have never denied that. Rijndael and TwoFish have not been broken no, but I never said that. But it can be brute forced, unlike a non-predictable key. I am aware that they cannot be cracked easily now, but they might be in the future, expecially if a weakness is found. That is the problem with the common method of encryption. But you must know this youself. I am not a security expert.

While it is nice to see an Australian join in the argument, you have to admit that as someone selling conventional encryption software you are highly biased.

 

Re: OTP

Maybe you would like to explain what methods you would use to make a key file unpredictable, and what exactly makes a file unpredictable? Going by your website are you implying

are unpredictable?

 

Predictableness

Excluding the Swap file, yes. Aside from a few bytes here and there (especially the header) they are mostly unpredictable. Ever tried compressing a JPEG? (I would make a challenge but I played that game last time and it got me nowhere.)

Obviously this is not the ideal for maximum security, but it is an option. I do say "In fact, if you use a good key file that is the same size or larger than the source and do not reuse the key file then it it impossible to decrypt the file, no matter how fast the computer is." and I explain in the readme what makes a good key. (I have a better expanation in my new version of CryptIt. This discussion has given me a lot to think about.)

I better go. I am late making tea...

 

Re: Predictableness

Well those few bytes here and there could be enough to give away the general message of the plaintext. Glad to hear you have come out of this for the better.

 

Re: OTP

We have already shown you that if you encrypt a text file with a key file that contains 0x00 bytes then every location where the keyfile contains 0x00 will result in visible plaintext in the output file. Yet you insist that "there is no need for the file to be random. It just needs to seem random to the hacker" and give recommendations on your web site to use JPEG files, the Windows swap file or even a music file, all of which can contain long stretches of 0x00 bytes.

You obviously do not care the least about representing your program factually - you have progressed to just wanting to win this debate no matter how wrong you are. The fact of the matter is that without a way to generate true random numbers your program is useless and provides the end-user with a false sense of security. And yet you have the audacity to claim on your web site that established algorithms such as Rijndael are less secure than your flawed product.

Perhaps you should consider that there is a reason why everyone in this thread is telling you that you are wrong. I suspect your reply will merrily ignore this and just state the reasons why you think you are right with blissful ignorance...

 

Null Bytes

Not at all. I am well aware of the problem of null bytes. I have explained this to many users and if you read the readme you will see that I say that it must have "...as few nulls as possible...". My new version (that I started on before this debate) has a feature to analyse files and will reccomend not using any file that is like that. It also will detect repetition and lack of balance. XorIt is a bad example actually. XorIt was written as a favour to a friend of mine who did not like all of the buttons that CryptIt has.

I have mentioned before anyway, there are other options such as Blum Blum Shub generators. But no one has even tried to counter that point. I will solve this whole delemma soon (in a month or so) anyway as I intend to write a OTP file generator. But don't worry, no more challenges. Feel free to keep an eye on the site however and label it as "Snake Oil" too. I am sure you will.

But how can I win this debate? Everyone else thinks that my programs and even OTP encryption are a sham. No one here will be convinced. We are all wasting our time. What I am trying to achieve is a balanced debate for anyone who does a search for XorIt and finds this sillyness. If I do not stand up for my software who will?

 

I wonder how many other vendors would be prepared to come out of the woodwork, and openly discuss issues like this about their products.

I don't know much about all the coding etc, and what's actually correct or not, but i think it's good to see Andrew Glina posting in a non offensive way !


Never heard of these, but they seem on topic !

. . .

Introduction

The purpose of this paper is to introduce the new random number generators IA, IBAA, and ISAAC. IA (Indirection, Addition) is biased but it appears to be secure. It is immune to Gaussian elimination. IBAA (Indirection, Barrelshift, Accumulate and Add) eliminates the bias in IA without damaging security. ISAAC (Indirection, Shift, Accumulate, Add, and Count) is faster than IBAA, guarantees no bad seeds or short cycles, and makes orderly states disorderly faster. The generator for RC4 will be used for comparison throughout this paper.

. . .

A sequence of new pseudorandom number generators were developed: IA, IBAA, and ISAAC. Their speed and lack of bias should make them useful for simulations and cryptography. The reader is invited to prove their security (or lack thereof).

http://www.burtleburtle.net/bob/rand/isaac.html


PRIZE, started 1998/february/6: $1000 (USA dollars) to whoever sends me the solution to the above challenge (plus publicly revealing a repeatable method for determining it) first. I'll also offer $100 for the first bias that can be detected with RANDSIZL=8 (in sequences of length less than 264 values) (starting with almost all seeds) (exceeding an absolute value of 4 times the standard deviation) (the test must start not knowing the seed).

ISAAC hasn't been broken since it was published 9 years ago. No bias has been detected either. I am offering these prizes in an attempt to get others to try to break it and assure those techniques are published. Apologies for having such a small prize. If you find successful attacks or biases in smaller versions of ISAAC, I'll include them in isaac.html, even though there are no prizes for them. I'm interested in attacks and biases against RC4 as well. Other fast stream ciphers are SEAL and WAKE.

2001: Marina Pudovkina published an attack on ISAAC with estimated running time of 4.67x101240.

http://www.burtleburtle.net/bob/rand/isaacafa.html


chi-square analysis of images.

So, once again, don't believe people who claim that steganography is undetectable. Especially their own secret algorithm that they will try to sell you, claiming that it has "military grade" and is of "world-class strength", "unbreakable even by the NSA". Ask them for a proof. Even better, crack their algorithm yourself.

http://www.guillermito2.net/stegano/index.html


StevieO

 

Hi Jason_R0,

You asked: "how long would it take them to decrypt all your encrypted files?"

-However long it takes to decrypt the multi-character password of the 7z files inside! If the 7z¼¯ headers are not exposed i would imagine someone(s) would stay busy with that DVD for quite some time. If they see those they'll probably taser me, or whisk me away me to gitmo.

Thats a big reason why i like Andrews program. You can't just beat the password out of someone.

 

If that's your main criteria, then you should be looking at deniable encryption algorithms like RubberHose not Xor...

 

Re: Predictableness

Yes, and you can compress JPEGs with all the most common compression algorithms (rar, zip, bzip2, gzip), although usually not by much. But slow compression algorithms like paqar are usually able to compress them quite a bit. You don't believe me?

Here, the first big jpeg I found on the Google cache: http://ice.unimi.it/alp/foto/CdA-04/weissmies/original/panorama dal rifugio.jpg

Size before compression: 824356 bytes
Size after compression (with paq6v2 -5): 796916 bytes

If you don't believe it, go ahead and test it yourself.

But that's beyond the point anyway. Regular image JPEGs are never, ever even close to resembling random. Using a randomness testing program, even a basic one like ENT, http://www.fourmilab.ch/random/, will show it right away. They utterly, completely fail the Chi-square Test every single time; and if you were to test the output of a true random source (i.e. radioactive decay) you would see it just doesn't fail the Chi-square Test.

 

Hi Paranoid2000!

Rubberhose looks very interesting.
How would you compare the plausible deniability feature of RubberHose to TrueCrypt's hidden volume feature?
The site http://www.rubberhose.org/ wasn't working for me. Is it live?

Also, I was wondering if there is some encryption software (within the reach of end users) that would allow for an incrementing rule set where the passphrase would change based on time, date, or better, a user specified pattern. A time or date based rule set could be attacked by constantly resetting the date/time. And the ruleset itself could be attacked, so that would need to be protected somehow (maybe encrypted also). But a custom user defined passphrase that increments or changes on each access might be possible. Some banks use those token cards (two part passwords), is there something similar that would be available to regular people?

Thanks

 

Oh yeah (that is, even if it worked as advertised):

Scenario 1:

Criminal: "Tell me your password or I will torture you".
You: "No!"
Criminal tortures you and you tell him the password.


Scenario 2:
Criminal: "Criminal: "Tell me where you hid the key or I will torture you".
You: "No!"
Criminal tortures you and you tell him where you put the key.


Scenario 3:
Terrorist: "Tell me your password or I will kill you".
You: "No!"
Terrorist kills you.


Scenario 4:
Terrorist: "Tell me where you hid the key or I will kill you".
You: "No!"
Terrorist kills you.


A big difference, indeed.

 

Thanks Paranoid2000.

@Devinco: http://en.wikipedia.org/wiki/MaruTukku

Still looking for MD5 of the original project files.. The location of the server is encouraging but with all the "war on terra" b.s. its not tinfoil to question their integrity.

 

There you go again! Not 1 of those scenarios apply to me. Securing the key is something that each person must work out on their own, and i have done so.
And no, i will not tell you how i do it so don't ask. If you want, start another discussion and we can all hash out the best storage solution. k?

Have you decrypted XORFileA.X yet?

tick-tock, lol.

 

Hi Devinco,

I found references to Very interesting looking RubberHose yesterday, but the website doesn't exist anymore as you discovered. I tried to locate more info and a DL via Google etc with no luck !

It seems that it was for UNIX only and never ported over to Windows, as far as i could determine anyway.

I think it's VERY strange that on all the numerous links i went to, not one of has a DL of it. I found a Parent directory for it with DL links, but they also failed ?

I wonder if the men in black have had something to do with eliminating it from the web, as it sounded like it was pretty strong stuff !

I did manage to find this and DL it, again No Wiki for it that's gone too, just a 404 !

. . .

PhoneBook is a filesystem for Linux computers.

PhoneBook is strongly inspired by the RubberHose project. However, in contrast to RubberHose, PhoneBook aims to be easy to install and use, targetted at intermediate Linux users and above.

PhoneBook (Deniable File System Encryption) alpha Build 011 06-Jan-2004

For technical info, please visit the User Manual | PhoneBook Wiki Pages | Block Diagram

http://www.freenet.org.nz/python/phonebook

. . .


StevieO

 

TrueCrypt's hidden volume looks like a similar feature but appears more restricted in that the documentation does not mention whether multiple hidden volumes can be used.

Current algorithms would require that data be re-encrypted if the key changes so it's unlikely that such a feature would be feasible.

Token cards (like the CryptoCard) are used for authentication rather than encryption (though they do use encryption as part of the process). In this case, the "challenge code" is what is constantly changing, rather than the key to megabytes or gigabytes of encrypted data.

With regard to Rubberhose, it would appear that other projects have taken up where it left off so thanks to _Lyn_ and StevieO for providing more up-to-date links.

Getting back to the initial topic of this thread, what it originally concerned was an attempt at implementing a One-Time Pad. While a proper implementation has been mathematically proven to be unbreakable (see Wikipedia: One-time pad) it has enough practical problems to make it unsuitable for most people. If you wish to encrypt 100MB of data, you have to have a 100MB key. How do you secure this? Storing it separately (e.g. on a USB memory stick) is little protection since it has to be present when you access your data. Encrypting it using a symmetric algorithm is better, but you are then depending on that algorithm's security, so why not just use it to encrypt the original data?

The one circumstance I could see OTP "adding value" for securing computer data is that of accessing data remotely via the Internet. In this case, anyone accessing the data would need to have a key (USB stick with the OTP) as well as know the password (key to decrypt the OTP).

For securing personal data on your own PC, the standard advice is to use open-source encryption software which is then subject to outside code review (sorry Jason), implementing tried and tested algorithms. So far, nothing posted here suggests any need to change that advice.

 

Interestingly, I intend to do something similar to that in a future version of CryptIt. What I want to do is to as well as use a large key file, I want to have several patterns (such as use only certain bytes in a block of a certain size, for example byte 1, 3, 9 and 15 out of a 32 byte block) that can be used to further reduce unwanted decryption.

I have always seen the need to store the key on a removable drive as a feature. I even have a special mode for it in CryptIt. Physical keys have worked for the same way for years afterall.

 

Ok, you're obviously a troll. So I won't bother with you ever again. Bye bye, pathetic loser... (and a busted one at that).

 

Due to Paranoid2000 comments Andrew just announced an upcoming additional feature, then you follow up with that? If you were familiar with Andrews program you would know what he means to use "certain bytes in a block" It will be a great addition to that particular feature! TNT, please stop calling me out and i wont have to continue posting in reply, which further mucks up the thread..

Thanks!

 

Sounds like something out of a Dan Brown book , Digital Fortress. LOL

 

_Lyn_,
Thanks for the link.

 

Hi StevieO,

On the page _Lyn_ supplied the link for, there is a link to the download page:
wiretapped rubberhose download
It is in a tar.gzip compressed format, so it appears to be a *nix program.
Whether it it contains any extra value added content (as _Lyn_ hinted), I don't know.
I'll be using Windows for a while yet, so that is not an option for me.
Thanks.

 

Hi Devinco,

Yes that's one of the sites i visited yesterday, the Parent directory. Even though the two files are listed as available links for DL, they don't seem to work for me.

This is what i get

http://img167.imageshack.us/img167/7686/rhnodl16pf.png

I only wanted to DL them to keep as they appeared to be very rare, and i or others might be able make use of them one day. That's the reason why i DL PhoneBook.

I've done this often with things, as sometimes they do disappear !!!


StevieO