Password strength

[docfleetwood]

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

[arunganesh]

{QUOTE-> 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 <-QUOTE}

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

[Jason_R0]

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-

[docfleetwood]

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.

[docfleetwood]

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?

[Jason_R0]

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.

[Peter2150]

Use a 40 character random password using the full 128 characters that can be used and do the math. If I assume 1 million computers could do 10million computations every microsecond it would only take in excess of 1 to the 10th power billions of years to crack the password. I think the hour pause is really unnecessary.

[docfleetwood]

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.

[xx3]

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.

[northstar51]

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

[Dazed_and_Confused]

{QUOTE-> i'm wondering what everyones thoughts are re password manager programs? good idea? bad idea? unnecessary? <-QUOTE}
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. 8)

[luv2bsecure]

{QUOTE-> 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. <-QUOTE}

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

.

[Jason_R0]

{QUOTE-> In fact, maximum full security in a 256-bit symmetric key, would roughly req
uire 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.
<-QUOTE}

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.


{QUOTE->
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
. <-QUOTE}

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.

[luv2bsecure]

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

.

[Jason_R0]

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

<-QUOTE}

Yes I realized this before I posted. :)

{QUOTE->
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

<-QUOTE}

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.


{QUOTE->
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.

<-QUOTE}

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

{QUOTE->
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.
<-QUOTE}

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.

{QUOTE->
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

. <-QUOTE}

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.

[luv2bsecure]

Jason,

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

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

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 (http://en.wikipedia.org/wiki/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

.

[Jason_R0]

{QUOTE-> 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 (http://en.wikipedia.org/wiki/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

. <-QUOTE}



From the CryptoSuite helpfile :-

{QUOTE->
Encryption Protocol

CryptoSuite uses two well known and secure symmetric ciphers for encrypting files in its archive. These ciphers are Rijndael 256bit and TwoFish 256bit. Each cipher has its own distinct key. The ciphers are used in Cipher Block Chaining(CBC) mode.

Two keys are generated from the same passphrase based on SHA256, MD5 and HAVAL256 checksums. These are used in various forms with many rounds (roughly 262144) to form distinctly individual keys for the Rijndael and TwoFish cipher. Each key is used with a random IV every time an encryption takes place involving that key. The IV is stored in the archive whilst the keys are not.

CryptoSuite encrypts FILE INFORMATION for each file in a compressed table which is stored at the end of the archive. This table is filled with random characters everytime file information is added to to the table to fill any unused space in the table.

FILE DATA for each file is pointed to by the file information table which contains each file's offset. File data is processed in 1byte to 1MB chunks read from the original file. The plaintext chunk is rounded up to a 16byte interval with random characters. This chunk of plaintext file data follows a chunk header which contains size information and a SHA256 checksum of the original plaintext chunk. This chunk header and plaintext chunk is then compressed and encrypted. The two IV's used to encrypt the chunk are then written to the archive followed by the compressed and encrypted chunk.
<-QUOTE}

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

[chriswr3]

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.

[Dazed_and_Confused]

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

[Devinco]

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.

[Tassie_Devils]

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. :P

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. ;D

Cheers, TAS

[stroppy proffessor]

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


{QUOTE-> 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

. <-QUOTE}

[Jason_R0]

{QUOTE-> 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 <-QUOTE}

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

[Defenestration]

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.

[luv2bsecure]

{QUOTE-> 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. :) <-QUOTE}

Jason,

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

Good luck!

John
Luv2BSecure

.

[S. Prof]

Yup,

FANTASTIC this is the way forward. If you can do this it would go down well with all and do you wonders

hope it fairs well

sp



{QUOTE-> Jason,

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

Good luck!

John
Luv2BSecure

. <-QUOTE}

[xmp]

Schneier means crunching an English key down into a cipher key. That's all he meant. 196 chars is not needed if the password is strong.

An example of a weakness was an early crypto program (not TDS, but this other company sells AV software too) which didn't utilize the full set of characters. Thus even the strongest key was weak.

The key bits may or may not be equal to block length in a symmetric block cipher. E.g. DES is 56 bit key and 64 bit block. An initial portion of the algo derives 64 bits from the 56 bits and uses that.

Multiple crypts can increase strength, but it depends on the algo (and implementation). For instance triple DES is simply DES 3 times, with 2 or 3 different keys. DES is thought to not be a group. That means encrypting once with Key 1 and then again with Key2 will result in cryptotext which cannot be cracked by a hypothetical Key 3.

Certainly using two random dictionary words as an online password is surprisingly safe. E.g. 1/100,000 * 1/100,000 which can't be broken via network cracking.

I agree with the implementation issue being as important as algo strength.

[luv2bsecure]

{QUOTE-> Schneier means crunching an English key down into a cipher key. That's all he meant. 196 chars is not needed if the password is strong. <-QUOTE}
Actually Bruce Schneier does mean using 196 characters for a 256-bit key. He even (in some of his writings) offers samples of how this might be done without killing your memory cells. Keep in mind, this is to utilize the full strength of 256-bit.

I personally heard Schneier discuss this at a CSI meeting in 2001 and that's really what he meant.

There seems to be some doubt about this and the only suggestion I have is to actually read his material or write him and ask him. I am sure he would be more than happy to explain in a nutshell and confirm this.
schneier@counterpane.com

John
Luv2BSecure

.

[Jason_R0]

{QUOTE-> Actually Bruce Schneier does mean using 196 characters for a 256-bit key. He even (in some of his writings) offers samples of how this might be done without killing your memory cells. Keep in mind, this is to utilize the full strength of 256-bit.

I personally heard Schneier discuss this at a CSI meeting in 2001 and that's really what he meant.

There seems to be some doubt about this and the only suggestion I have is to actually read his material or write him and ask him. I am sure he would be more than happy to explain in a nutshell and confirm this.
schneier@counterpane.com

John
Luv2BSecure

. <-QUOTE}

If you take a look at a 256bit key (32 bytes), there are 2^256 different keys. So if you tell me you have a 256bit key I know it's a number between the range of 0 to 2^256.

You shouldn't get confused between passwords and keys. Passwords are TYPICALLY used to generate keys. In some implementations, the password is even the KEY itself. So lets take the key generation part out of it and just say you use the password as the key. Lets say your password is 8 bytes, but the keysize you are using is 32bytes (256bits). So if you didn't generate a key from your passphrase and instead used your passphrase as your 256bit key, it would look something like this :-

MYPASSWD000000000000000000000000

(taking into account that each 0 is one BYTE)

Now this key is nowhere near using the full range of what is possible, look at all those zeroes. Effectively your key is now only 64bits (considering your password is completely random and uses each full byte for each character)

But what if I just generated 32 random bytes for my password/key? Then you would be using ALL of the security that a 256bit key offers. So considering the your password is random and you use the password as your key then you only need 32 characters to fully utilize a 256bit key. If you have trouble understanding this, I suggest you re-read it then possibly do some other research if it's still unclear.

Now, maybe there is some mis-understanding going on here. If you are trying to suggest that when you use cryptographic hashes to generate KEYS from passwords, that the password should be 192 characters for better security, then maybe you are right to an extent. Evidence suggesting certain hashes are "weak" given a smaller message length than 192 would be helpful however. :) As far as I am aware, Bruce Schneier has never said this.

[luv2bsecure]

{QUOTE-> You shouldn't get confused between passwords and keys. Passwords are TYPICALLY used to generate keys. <-QUOTE}

Hi Jason,

I promise you - I know the difference. In extreme simplicity: passwords or passphrases are used to derive keys for cryptographic use.

Talking about all of this has made me think again, that when it gets right down to it the fact is, the use of a password (or passphrase), in most cases and especially for high security use, has become obsolete! However, if one chooses not to use pseudo-randomly generated keys, it is not easy to remember and is most inconvenient, but that is what people seem to want to do!

random+salt. Personal entropy. Information theory - this is all important but unaddressed. The use of MD2, MD4, and MD5? I still don't understand that. Speaking of:
www.arnnet.com.au/index.php/id;1503863220;fp;16;fpid;0

I have so many questions as to what you know about cryptography at the mathematical level. What is your crypto training? No offense intended. Maybe it's just a different way of looking at things - or we are missing something here. Maybe miscommunicating? That wouldn't be a surprise in my current state of health. (Sometimes things are mush.) One thing I know in crypto: 2+2 doesn't always equal 4.

By the way, concerning cryptographic keys, passwords, etc. and trying to safely secure the info in the brain --- here is something else I think you might find very interesting:
http://www.schneier.com/paper-personal-entropy.pdf

best,

John
Luv2BSecure

.

[xmp]

John is correct about entropy of passphrases.

"If the phrase is long enough, the resulting key will be random. Exactly what 'long enough' means is open to interpretation. Information theory tells us that standard English has about 1.3 bits of information per character. For a 64-bit key, a pass phrase of about 49 characters, or 10 normal English words, should be sufficient. As a rule of thumb, figure that you need five words for each 4 bytes of key. That's a conservative assumption, since it doesn't take into account case, spacing, and punctuation."

Applied Cryptography (Bruce Schneier)

Extrapolating, it's 196 chars for 256 bit key. IF it's an obscure English phrase, preferably not from any book in print. Entropy of a pass phrase is a social construction though.

[Jason_R0]

{QUOTE-> John is correct about entropy of passphrases.

"If the phrase is long enough, the resulting key will be random. Exactly what 'long enough' means is open to interpretation. Information theory tells us that standard English has about 1.3 bits of information per character. For a 64-bit key, a pass phrase of about 49 characters, or 10 normal English words, should be sufficient. As a rule of thumb, figure that you need five words for each 4 bytes of key. That's a conservative assumption, since it doesn't take into account case, spacing, and punctuation."

Applied Cryptography (Bruce Schneier)

Extrapolating, it's 196 chars for 256 bit key. IF it's an obscure English phrase, preferably not from any book in print. Entropy of a pass phrase is a social construction though. <-QUOTE}

Yes that is the point I was trying to get across, if you have low entropy you will of course need more characters for your passphrase. The idea that everyones passphrase needs to be 196 characters is what I originally said was misleading. And as I have been saying, if you have 32 characters with full entropy (ie randomness), then you have maximized the security for a 256bit key. You will mostly only get this sort of entropy if you generated 32 random bytes for your key, not from a standard password choosen by the user.

{QUOTE-> In fact, maximum full security in a 256-bit symmetric key, would roughly require around 196 characters. <-QUOTE}

That quote is only true if entropy is as xmp mentioned, at around 1.3bits per character. This wasn't mentioned in the original quote which is why I added my comments. If you re-read my posts you will see I also say roughly 20 (considering most passwords can only use 7 out of each 8 bits) characters is needed to fully satisfy a 128bit key when you consider it has full entropy, which John also said he wasn't going to agree with. :)

[Dazed_and_Confused]

Well, I'm not too sure I followed everything said above. :o :o But what I do know after reading this is that I'm feeling pretty confident that I made the right decision to buy Cryptosuite, and that the folks that wrote Cryptosuite know what they are doing (understand cryptography). :D

[luv2bsecure]

{QUOTE->
Well, I'm not too sure I followed everything said above. But what I do know after reading this is that I'm feeling pretty confident that I made the right decision to buy Cryptosuite, and that the folks that wrote Cryptosuite know what they are doing (understand cryptography).
<-QUOTE}

Dazed and Confused:

Be thankful that you made your purchase from people willing to talk to their customers. Dialogue from the developers - with open discussion - is rare in crypto programs. Whatever else I might think, I believe that Jason and the crew at DSC deserve the highest of praise for that. They're good people.

John
Luv2BSecure

[luv2bsecure]

Indulge me for a moment. The following is page 348 and 349 from Practical Cryptography by Bruce Schneier and Niels Ferguson. To fit, I had to cut the images a bit, but it's all here. Read these passages carefully. By the way, this book is not the same as Applied Cryptography. This book was written for the lay person, so it should be easy to understand. The information below is copyright 2003 by Niels Ferguson and Bruce Schneier......
http://img.photobucket.com/albums/v333/thejuggler/348.jpg
http://img.photobucket.com/albums/v333/thejuggler/349a.jpg
http://img.photobucket.com/albums/v333/thejuggler/349b.jpg

This is very self explanatory. It easily explains the approximate amount of entropy per english character. It easily explains what I have been trying to say in this thread. I have decided I am not communicating well, so thought this would be the best way.

Pay careful attention to the fifth paragraph. In other writings, speeches, interviews, etc. he explains the need for the use of long passphrases. He doesn't always think people will do it (as it can be complex) and considering this was written for the lay person dismisses what SHOULD be done as unacceptable for the lay person. But for high security and to maximize security with 128-bit (as in this example) here it is! This is with my optimistic 2 bits per English character. At 1.5 - it is longer.

For 256 bits of entropy ------this is how you get the 192 characters I referenced in the earlier post. BTW, the next page discusses using a limited-entropy passphrase along with a random number stored alongside the data that was encrypted with the password. This is called "salt"....a good way to beef up an otherwise weak passphrase. Also, page 340 explains why the passphrase for Alice, in the example from the book above) is not truly good because of the dictionary words and how she can do better by using the first letters of a string of long words from a memorized passage.

If you would like further information - or verification - as to why the long passphrase is needed to make the most of the 128/256 ciphers, please write Bruce. He (usually) is good about responding.
schneier@counterpane.com

All the best,

John
Luv2BSecure

.

[Jason_R0]

{QUOTE-> Indulge me for a moment. The following is page 348 and 349 from Practical Cryptography by Bruce Schneier and Niels Ferguson. To fit, I had to cut the images a bit, but it's all here. Read these passages carefully. By the way, this book is not the same as Applied Cryptography. This book was written for the lay person, so it should be easy to understand. The information below is copyright 2003 by Niels Ferguson and Bruce Schneier......

This is very self explanatory. It easily explains the approximate amount of entropy per english character. It easily explains what I have been trying to say in this thread. I have decided I am not communicating well, so thought this would be the best way.

Pay careful attention to the fifth paragraph. In other writings, speeches, interviews, etc. he explains the need for the use of long passphrases. He doesn't always think people will do it (as it can be complex) and considering this was written for the lay person dismisses what SHOULD be done as unacceptable for the lay person. But for high security and to maximize security with 128-bit (as in this example) here it is! This is with my optimistic 2 bits per English character. At 1.5 - it is longer.

For 256 bits of entropy ------this is how you get the 192 characters I referenced in the earlier post. BTW, the next page discusses using a limited-entropy passphrase along with a random number stored alongside the data that was encrypted with the password. This is called "salt"....a good way to beef up an otherwise weak passphrase. Also, page 340 explains why the passphrase for Alice, in the example from the book above) is not truly good because of the dictionary words and how she can do better by using the first letters of a string of long words from a memorized passage.

If you would like further information - or verification - as to why the long passphrase is needed to make the most of the 128/256 ciphers, please write Bruce. He (usually) is good about responding.
schneier@counterpane.com

All the best,

John
Luv2BSecure

. <-QUOTE}

Hi again John, :)

What you are saying is correct, I am not saying it isn't. The difference between something being misleading and something being incorrect is sometimes very great.

Now for the normal everyday average user who wants to use encryption and isn't good at remembering very obscure and random passwords, then maybe using 10-15 english words which form 196 characters is the best thing for them if they want to ensure their 256bit key has enough entropy. I'm not saying this is wrong, and possibly even most people would fall into this category.

However for another semi-typical person there is another step they may take, if you generated 32 random bytes for your key and spent some time memorizing it, then you have just as much security as someone who memorizes the 196 character phrase. That is all I am trying to get across, the amount of entropy in a password IS variable, not all passwords are the same. Of course one might be easier to remember than the other, but I didn't think we were discussing that. :)

Thanks for providing those images, I am sure a lot of people will appreciate them. :)

[Jason_R0]

{QUOTE-> Yes I am not sure why so many other encryption software authors shy away from public support. It might be something to do with a lot of people just using 3rd party encryption libraries without really knowing much about cryptography. I am glad I am not the only one who has noticed this, shows you know a lot about the industry John. :) <-QUOTE}

Yes I am not sure why so many other encryption software authors shy away from public support. It might be something to do with a lot of people just using 3rd party encryption libraries without really knowing much about cryptography. I am glad I am not the only one who has noticed this, shows you know a lot about the industry John. :)

[Zedd]

Just wanted to post a link to an FAQ about passphrases.
IT's a bit old and is related to use of old PGP software but
most of it can be universally applied.

http://www.stack.nl/~galactus/remailers/passphrase-faq.html
The passphrase FAQ, version 1.04
Randall T. Williams

[entropic]

This is how I generate good passwords (steps 2) to 4) of this are easil;y converted to a Perl or Python script -- write your own script and test carefully that it's giving random results):

1) Pick a password strength in bits: for current use, I'd suggest a minimum of at least 64 bits, for the paranoid or for very long term use 128 bits (long term here being long enough for quantum computers to go from lab research to hacker's desktops). Round the number of bits up to a multiple of 6, and divide by 6 -- this gives the number of characters long that your password will need to be (i.e. something in the range from 11 to 22 characters)

2) Using a source of cryptographic-strength entropy (i.e NOT rand() or anything derived from it -- on Linux /dev/random words fine, or roll a lot of dice, or take a LOT of gibberish input from the keyboard, making a very conservative assumption like 0.25 bits of entropy per character of gibberish) generate a chunk of data containing more bits of entropy than the number of bits of password strength you picked (and ideally at least 128 bits of entropy, or 160 if you plan to use SHA-1 in step 3)).

3) Hash the entropy-containing data using a cryptographic strength hashing algorithm like MD5 or SHA-1 to compress the entropy into 128 or 160 bits (while MD5 does have some known issues for message integrity uses, none of them should affect this use, which is just compressing entropy).

4) Base-64 encode the resulting hash (converting it to a string of upper and lower case numbers and digits, plus possibly a '/' or a '+'), and take the first however many characters you decided you need for you password length (be sure to just take the first N characters, don't pick out N characters you like from the entire hash, the latter is a weaker password). This password is extremely secure (but so far for most people very hard to memorize).

5) Staring at your new password, spend some time devising a meaningful (or at least as meaningful as you can come up with) and memorable phrase whose first letters are the letters of your password (for numbers, either put numbers in the phrase or use soundalikes or lookalikes like '1' -> 'I' or 'wan', '8' -> 'ate', or any similar trick you can think of). You can either just memorize the MiXeD-cAsE nature of the password (e.g. by thinking of the UPPER-CASE words as being LOUDER or EMPHASIZED), or you can use proper names in the phrase for upper case letters and other words for lower case letters. [Personally I find making the phrase as obscene as possible helps me remember it, but that may be a quirk of my particular twisted brain.] The phrase isn't your password (though I suppose if you wanted to (and can touchtype), you could use the phrase as passphrase as a very long password, it should have even more entropy than the entropy of the set of letters you derived it from), it's just a mnemonic device to help you remember the random password you generated in steps 1) through 4).

[If you have a lot of trouble generating a phrase for the password you got, you could generate another password and try that one, or do something like swapping all the letters between upper and lower case, but bear in mind that you just gave up about one bit of password strength by doing so -- doing it twice more will lose you another bit, four more times another, and so on, so soon you may need to add another character to the password length to make up for it.]

6) Memorize the phrase. Practice (on a secure system) typing the password from the memorized phrase until you are sure you have it memorized and can do it easily. This is likely to take multiple repetitions. During this process you may think of or discover ways to improve the phrase's merorability or how much sense it makes -- this will help in the long run but may require some extra memorization work at this point.

7) Actually change you password on the system this password is for to the new password. If the system you are entering the password into complains that it isn't secure enough because it has only letters and numbers and no symbols in it, laugh hollowly and convert one of the numbers or letters into a symbol in some memorable way such as 'S' -> '$'. Rememorise you passphrase with this extra twist, or change the passphrase to fit this and rememorize.

8) Now that you have gone to all that trouble, if at all possible, never write your password or the corresponding phrase down, never enter it into any sort of insecure computer system, don't use the same password for any other sytems (at least not unless you have total faith in their security), don't tell your password or the corresponding phrase to anyone, and don't let anyone watch over your shoulder (or listen to you mumbling the phrase) while you type it (though if someone does watch over your shoulder without you noticing, they may have trouble memorizing the string of random letters and digits you are typing).

[entropic]

Obviously steps 2) through 4) and 6) need to be done on a secure and trusted system, and erasing the results from memory or disk as much as is practicable is probably a goos idea too.

[BourgePD]

For generating pass phrases at the most basic level, I have a preference for using the 95 printable characters abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,./<>?;':"[]\{}|`1234567890-=~!@#$%^&*()_+ and using a password generator to generate them. Examples from a self-generated one-time pad containing 100k pass phrases:

81690: ga}XmRPeGsZ+\V?GPzFDSNK`:/Mm:r:?vCq%o7YDK$XpRDmG~sm,t)QOZo$~*oF+$:wc3VsWht'?:4D0=(1odH\`NjU]jV
81691: BMLPnq<e/89_TQ|{J05'A#I:g"2;n/4Q(%K;W0+>mw#dj?yD{PlS/\k?fZuxrs>)kzyV\[x<A!W?;(>s21d>o=;`A2$a!N
81692: !]+x8S;c2%r8-f0Y.^xCEyP'rAIdB4(F0VM@F)%_`uBgsZhj[-?|-J@EE*_x,l96BIiX(C3G2Hkk:Q3t`Ub09\hq(s,]?D
81693: p4O^3fY%g1WH\"U;_WH1%y["Pb,Y@r1e4E!(|XX\~`^*R#o#{7lK~lro.2;B.P/x[hF:hj.PJvfO`I0l_<0ru(QkeNUf'd
81694: diLaUIKM.o)Kf|J'pJC|Omwq>)791uo]~B~\[sZEUj&cZj_-]uKjm/NQe5?3&u+ZGIEsUl?@K~*#*!7pn=/@Rd*{>$ca_B
81695: ,-Y=/]bpo+iAf{8='+~U#y>|]sPDT\&sM%AdrB7g&JO|#D()xEJJ_(/a&EqcMc;.b#">]gsIRl<}BibX\;.)'&;dB![cZn
81696: 3Y(qyJ-x9+|7&sB[f.($qW<HWAC9`%0[i;zcW3*4="K^\JdVau%w!^S`D2bO!d#B|I>be&Z'!>I}"QXP6T`^~TG&Aqd1K7
81697: WW<$C/>quMu%GKIC,J<J>0d]eCuY4fnXi51qMra}IbrUd~_/adJ|94el?eu[-/0@KJ%1ZwS^"!=0M:<W;:">PMkFf"8SHD
81698: ]wWq^I"m1XRF\P)P\FU[uwvAEp;nT4jVAFea/%KBP/aee69|J3m[AeR5^8t!JsNaM^9B}>e(4.;]G@B7^,ow^:U<]TOC}q
81699: /B@"d;N'4^o$AY!rV?aQ<aYyO6yKZ"$lqf9|MB0iuzEb_ywC`-sdwkKME$._nevhTVT{$bF;Ee*C)Al[~p2gc'FdrDHUtn

Much more secure than easy-to-remember text strings. Needless to say, other than that these keys just expired ;) , key management is a whole other topic.

:lurking: