Password strength

I was recently reading through the CS help file regarding bruteforce attacks against the key and the password. In the attacks against a password using only lowercase letters a-z you mention that there are 11881376 different combinations (I think this is right - I don't have the info with me) when using a 5 character password. It would not take a computer very long to try these various combinations so increasing the number of possible characters and increasing the size of the password greatly increased the security of the encrypted file.

So, on to my question.....

Wouldn't the use of a duel password system give greater security benefits? The way I see it, and my math may be off but I think it is right, if a program required 2 passwords (and in a specific order) then two 5-character passwords with just the letters a-z would yield 11881376^11881376 combinations - no? This number seems to be rather large for even simple 5-character passwords. If I am not mistaken, the bruteforce attack would have to try every 5 character combination with every other 5 character combination - hence the large number above. This is bigger than the number of possibilities with a 10 letter combination if you were to use a single 10 character password. Combine this with the use of more than just a-z and it seems to me that even relatively simple passwords would make an encrypted file secure if 2 were required. Is my math way off?

I'm interested to hear your thoughts on the subject.

Tom

 

Hi

your Idea is very good. when the intruder checks the duel password one by one means I would be easy to predict our password. It's my opinion. It's may be right or wrong. Anyway I congrats You for this different view

 

Hi docfleetwood, it is a good question.

5 characters with 26 combinations (26^5) = 11881376
10 characters with 26 combinations (26^10) = 141167095653376

2 x 5 character passwords with 26 combinations (26^5) = (26^5) x (26^5) = 141167095653376

It is actually not 11881376^11881376 but rather 11881376 x 11881376 .

So it is the same amount of combinations whether 2x5 char passwords or 1x10 char password.

-Jason-

 

Ahh, yes - I sat down and did the math on paper (rather than in my head) and I agree - it does work out the same. Thanks for the clarification. I had seen this technique in a program called 'scramdisk' - and older encrypted virtual drive program where you could put in up to 4 passwords to encrypt your data. The attacker not only doesn't know how long your password(s) is/are but doesn't even know how many to try at one time - it could be only one or could be all four. It just seems like it should be soooooo much more difficult that they wouldn't even try to crack the password(s) but move onto a program with a single password box. Mathematically, I agree with your numbers. Intimidation factor - it seems much more intimidating

On the other hand - if you had more than one password box and people used their normal password in box one (say 8 characters or so) and even put in a simple 3 or 4 character password in box two (let alone boxes 3 & 4) that would make the encryption significantly more secure. Now, no more secure than an 11 character password but I think as a matter of behavior people would use the second password box with a simple password before they would extend their normal password by 3 or 4 more characters. But that is just my opinion of people's behavior and doesn't mean it is the right thing to do

Again, thanks for the clarification & have a great day.

 

Jason,

What effect, if any, does limiting the number of password attempts have on bruteforce password attacks. In other words, if after 10 password tries the program locks down for a given amount of time - say an hour - before you can try the password to decrypt a file again. Would this effect bruteforce password attacks or do they somehow just get the program to spit out keys for each password they want to try and then use these keys to then try to decrypt a file without ever actually using the encryption software password box? I hope that made any sense

Obviously if it is the former then it would take significant time to try even a 5-character password when you add an hour (or any time interval) every 10 wrong answers. But if they generate keys and use them then they would bypass that security measure. In effect, I guess the question is - does an encryption program generate the exact same key each time the same password is used or is there some randomness to it?

 

Yes of course the same password must generate the same "key" . There is randomness when encryption takes place which ensures that every encryption is never the same using the same key.

CryptoSuite does over 100,000 rounds on the password (this does take some time around one second or so on my 2.2GHz machine) which increases bruteforcing time a lot.

It doesn't matter if I put a delay when entering the password or not because a proper bruteforcing program would not even use CryptoSuite to bruteforce the key/password, they would use CryptoSuite's algorithm in their own program. Obviously this doesn't affect the strength of CryptoSuite as it uses secure algorithms and a secure file format.

 

Disconnect your computer from the net and shoot anyone who goes near it and encryption software is really unnecessary too

But I commend you folks who use 40 character passwords - I have enough trouble remembering my much shorter ones.

I'll obviously have to do some reading up on encryption and the terminology because I have an idea that I think could make the bruteforce attacks unfeasible even for smaller passwords - but again, I'll have to do some checking first.

Have a great day all.

 

40-char passwords are unnecessary. The risk of having a keylogger or hardware interceptor capture the password--or of being interrogated and forced into giving it up--grossly exceeds the likelihood that even a (good) 20-character password will be brute forced. Using 40 characters, for most people, is something like putting the door from a bank vault on their house, right next to glass windows.

 

i'm wondering what everyones thoughts are re password manager programs? good idea? bad idea? unnecessary? i'm going to assume these types of programs increase ones vulnerabilty, but if someone desired the convenience of having to remember only one password, are there any strong negatives to these programs? i viewed a free password manager offered at bruce schneier's website (www.schneier.com) and was wondering--since it's free--if it was useful to use? thanks as usual for any input here...ns51

 

Sorry for the delayed response. Just got around to reading your post, NS51. I use RoboForm. It use DES3 encryption and can remember all your passwords. All you have to remember is ONE. It will even remember your CS password for you! It's free, but I liked it Soooo Much, I paid for the full version. I highly recommend it.

 

I would tend to disagree if one is wanting strong encryption security. As we have gone from 64-bit, to 128-bit, to 256-bit key lengths - it is imperative that the passphrase increase accordingly. It does no good to use encryption supporting 256-bit key length and only use 8, 10, 20, or even 30 characters in a passphrase. This is all mathematics and "information theory" at work and there needs to be some understanding of that to understand the need for the longer passphrases.

In fact, maximum full security in a 256-bit symmetric key, would roughly require around 196 characters. If one isn't prepared to do that in common everyday use of encryption - a 64-bit cipher at 26 characters is actually more secure and you just as well use one of those - and for most people's needs, that's probably okay. But, to generate a secure hash value utilizing SHA-1, SHA-2 or MD5 requires a solid (and sometimes long complex) passphrase. That's where random passkey generators utilizing true random characters can be a big help and then storing it in a cryptographically strong external "key" rather than a passphrase. How do you keep the "key" secure and safe? That's another post.

But with a long passphrase made up of random letters (upper/lower), odd characters, numbers, space, etc. and using one that makes sense in some strange way for you - you'll end up with a solid passphrase that will at least provide maximum security for a 128-bit key strength algorithm. But, I wouldn't settle for twenty-something characters as anywhere near secure for 128-bit length. Unless, again, you just want to hide something from the kid sister.

John
Luv2BSecure

.

 

I would suggest you might need to do the maths again on that one. 196 characters for maximum full security with 256-bit symmetric? That relates to 1.3 bits of entropy to each character of password. I know my passwords have a lot more entropy than that, but I am interested as to where you got the idea that the average was 1.3 bits per byte ?

I also think the suggestion that you need an extremely long and complex set of data for SHA-1/2 and MD5 to be secure as misleading.

Actually ~20 character passwords (considering full entropy) are all you need for 128bit level encryption. Anything more than that is not needed. However you need to factor in that your password will unlikely have full entropy, so it may need to be longer.

Unless you pick an easy word for your password, then an 6-8 character password would be all you need to stop your sister. Unless of course your sister knows how to perform dictionary attacks, works for the NSA or has installed some spyware on your machine.

As I have said before, if you can remember only one good password in your life, it is better than a million average ones. You just need to pay careful attention to not using your password when it can be snooped. Only use your good password when securing files/data that are local to your machine. Don't use your extremly good passwords for internet banking/websites/video store, etc.

 

I really was not referring to CryptoSuite, BTW, just answering a general passphrase-length question.

You know, this is very controversial. I would, with good grace, disagree that twenty characters is all that's needed for 128-bit encryption. I'm tired and don't want to go into it all, but I will refer you to someone we might both agree is fairly knowledgeable on the subject: Bruce Schneier. He is very much a critic of claiming strong security with as little as 20 characters with 128-bit. He describes this in great detail in his book Secrets and Lies.

Here is a reference to his thoughts on the subject:

Strictly, it's not the length of the key, but the "entropy" in the method used to derive the key. From memory, I think there is about one bit of entropy in an normal ascii character. If you derive a 128-bit key from a password or pass phrase, you will need a very long pass phrase to get enough theoretical entropy in the key to match the security of the underlying key length: Bruce Schneier estimates that you need a 98-character English passphrase for a 128-bit key.
http://www.di-mgt.com.au/cryptokeys.html#howrelevantiskeylength

Okay, my "kid sister" comment was silly. Of course, a simple random word will keep it secure from the sis if it's something like "ammunition".....no kid sis will get that....it was a bad choice of relatives. Anyone with access to dictionary attacks though will break it in - not minutes - but seconds.

Again, in my opinion, and there are many, a single "good" password is a horrible idea. If the passphrase is compromised - you could give it all up before you even knew anything was wrong. After all, containers (for example), under your plan, would all have the same "good" passphrase, right? As opposed to being compromised and leak information from one source - it's acceptable to leak it from 5? 15? 30? More? A single password is discouraged by most every cryptographer I have ever conversed with. But, again, it's perfectly okay to have a different opinion and I respect that. But, I would make clear that the "single passphrase as long as it's good" is a minority opinion in the crypto community.

I have looked through the CryptoSuite site and forums and it's all interesting. The algorithms used are solid. However, as far as hash function, I am curious as to the implementation of MD2, MD4, and MD5? Also, I think it would be great to put up a whitepaper that would include more cryptographic documentation for the security professional who might be evaluating your product for use in their environment. One other thing - I was a little confused by the nomenclature used in describing the "bits" of Rijndael and Twofish. In some parts it seems to be referring to key-length, yet in others block size - I was a 'bit' confused
-- pardon the pun. But, what about block size in your cascading function?

There seems to be some interesting features, and a fairly intuitive GUI, but I would like to see more documentation provided on the implementation. Also, any plans to release the source code? I personally, with other options available, shy away (for the most part) from closed-source, commercial products. Is that something that is being considered?

John
Luv2BSecure

.

 

Yes I realized this before I posted.

I find that comment misleading. What exactly is his idea of "a normal ASCII" character? What he says initially though is correct, it is the amount of entropy that is most important. And the most amount of entropy (in bits) you can have for each BYTE is 8 bits (obviously). So if we were using totally random 8bits for each character of the password, then we would have the full 8bits of entropy for each character. Considering full entropy for each character, then you only need ~20 characters to fully utilize a 128bit key. There is no disputing this.

There are people who will say that most english sentences/words/phrases have something like 1bit of entropy per character, and in most cases they are right, but not everytime. This is probably what Bruce was referring to.

It's always good to have a little fun with encryption.

No no, you misread. A single good password is better than a million average ones in regards to protection against dictionary attacks, bruteforcing, etc. Of course if you factor in the fact that passwords can be stolen ( I wasn't factoring this in) then maybe a million average ones would be better. I was discussing more in the terms of security of the passphrase itself.

All the encryption and hashing parts of CryptoSuite are open-source. You can view the relevant links in the helpfile to see that.

The actual file format and specific pecularities are discussed in the helpfile but aren't open source.

 

Jason,

Thanks for your reply. We'll leave the 128-bit/passphrase length alone for tonight. I'll agree to disagree.

All of the well-known algorithms (AES, Blowfish, Twofish, Serpent, MARS, etc.) and hash algorithms are open-source and available anywhere. All of them can be obtained from many different open-source cryptographic libraries. It's not that part that is of concern to me.

We must make sure everyone understands the difference between open-source crypto design and open-source crypto implementation. As I am sure you know, they are two very different things.

The real key to the security of applied encryption is in the implementation by the developer of software utilizing the open-source algorithms. You can throw AES at 256-bits utilizing a SHA-256 hash at a developer - and unless he is a cryptographer (or consults closely with one) you could end up with a totally insecure piece of encryption software. That is why I think the source code should be available for the program itself, or at least have it verified by leading (and named/signed) cryptographers. There are too many questions otherwise. CBC? CTR? Authentication? Whitening? MAC? Authentication is more important, many believe, than the actual encryption itself. Any good cryptographer worships at the shrine of Kerckhoffs' Principle.

I know that closed-source commercial software developers try to attain marketing mileage by repeating, over and over, that the encryption/hash algorithms are open-source. This is, of course, true with every single commercial encryption software package. But the key, again, is how was the open-source algorithms and hashing implemented? At one time, Counterpane studied 5 well-known, heavily marketed commercial encryption software packages and found that 3 of the 5 had serious flaws in their implementation of the cryptography. The conclusion was that the 3 software packages were useless - as they would give up the secrets easily to anyone trained to retrieve them.

So, the source code for CryptoSuite itself is important. Without it, everyone must merely trust that you are correctly implementing all the open-source algorithms. This is why PGP, Truecrypt, AxCrypt, etc. (all open-source) have exploded in popularity. TRUST - but VERIFY. The end-users are finally understanding what cryptographers have known forever - it's in the fine science of implementing cryptography that makes a program secure (or useless). And as nice as ease of use, GUI, etc. can be, ultimately security is what it's all about.

I am up way too late and must retire for the night. I have enjoyed our discussion and I wish you the best of luck with CryptoSuite.....even though I might wish you would "open the hood" and let us see that the engine is properly connected to the cooling system.

All the best,
John
Luv2BSecure
As an afterthought I am editing this post to include an essay that I think says everything I said above, but in a more orderly and detailed fashion if you, or anyone else, is so inclinced to read it:
http://www.schneier.com/essay-028.html

.

 

From the CryptoSuite helpfile :-

If I can describe the process which CryptoSuite uses in the helpfile , let me tell you I can code the process which I describe even better.

Many months were spent ensuring that the methods I used were not only very good/secure, but were also bug free. I also invited independant coders to also looked at this implementation during the development of the program, and none of them found any problems. This didn't come as a surprise to me because I have checked and rechecked all crucial parts of CryptoSuite 20-40 times (depending on which part).

 

Hi everybody,

I read through the forum but could not find any satisfying answer...

Password strength in the German version is really good:

Enter - when you create an image - a pwd with german umlaut and acronis does accept it.

When you want to rewrite the image, you are not allowed to use the german umlaut...

So the backup is very secure - nobody can access it anymore - not even you ;-)

OK, that's the funny side of life...

Is there anybody who can tell me if there is a workaround? (in other words: HELP)

I tried all characters from the keyboard for the german umlaut-o, the combination ALT-0xxx is not beeing accepted.

 

Jason / Luv2besecure: Excellent posts. Although I have to admit that I had to read each one a few times (and very slowly) to understand it all.

 

Agreed, this is how us mere mortals can learn a great deal in a short time.
The open source versus commercial interest(preventing competition/protecting trade secrets) is very interesting as well.
If the developer releases the source, then anybody with a compiler could get the software for free. But if the encryption software is analysed by an independent analysis lab (Counterpane?), then the developer could keep the source code from being public (only releasing to the analysis lab). It would provide a trusted third party review that could either confirm the product's strength and/or identify faults and ways to make it even stronger. Since encryption software is a munition, I think a third party analysis could only help make a great product even better.

 

I just had to sprout wings on my furry little body to try to reach the stratospheric heights of encryption for us mere mortals, alas, I crashed and burned.

I am with you Daisey, long, slow and only 1/10th sunk in.

Still as Devinco says, it's a very good read.
Thoroughly enjoyed a civilised debate on the merits of individual methods.

Cheers, TAS

 

Jason,

Gotta agree with Luv2BSecure here, you should have nothing to be shy of or hide, for wider scale application you will need to have this peered or open up.

You dont have to give it to the public, but have it peered by a well known cryptographer.

If he finds that he cant crack it and declares this, although thats not the means to an end .....everyone will want to get this product,

right now you have a neat little application, very little documentation and and a lot of unevaluated faith in yourself,

otherwise keep up the good work

 

Yes, I have no problem with getting another 3rd party to take a look at CryptoSuite. After the next release I will try and find someone trusted that can do it. It would look good on the homepage.

 

My recommendation for a password manager would be KeePass ( www.codeproject.com/tools/keepass.asp ). It's open source, uses very strong encryption, and has a great interface. It also has a very useful feature which allows you to create key disks. This allows you to create a very random password (not easy to remember) on a floppy disk/USB memory stick, and you just need to insert this disk when asked for the password.

 

Jason,

Wow! You are to commended. That's a BIG step in the right direction.

Good luck!

John
Luv2BSecure

.