Recent

Author Topic: AES Encryption  (Read 8070 times)

Trannel

  • Newbie
  • Posts: 1
AES Encryption
« on: July 29, 2014, 10:35:18 pm »
Hello Guys,
your crypto-knowledge is wanted  :D

At the moment i'm coding a program which should be able to keep the passwords of the users. Of course i don't want to save them in plain text, so i thought out sth.

The passwords will be saved AES256-CTR encrypted, but this is secondary. I want to ask you, what you think about the key and IV generation.
So first the Key.
The key is at first about 70 characters long and consist of computer-specific things like OS or Username. To get to the 256 bit length, this key get hashed, using SHA256. So at the moment the key is on every PC Unique. But in the next time i want to make more unique.

Now to the IV. The IV is 128bit long and consist out of parts of the key, because i don't want to save the IV anywhere.

And after that, the Password gets encrypted. What do you think about it? Are there any weak spots, which i didn't care about?
Thanks for your replies  :)

taazz

  • Hero Member
  • *****
  • Posts: 5368
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: AES Encryption
« Reply #2 on: July 31, 2014, 10:10:48 am »
No idea about details of IV etc, so cannot comment.

However, encryption key management is also very important.
See here
http://forum.lazarus.freepascal.org/index.php/topic,17651.0.html
though it is a bit of a long thread.
Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

MathMan

  • Sr. Member
  • ****
  • Posts: 325
Re: AES Encryption
« Reply #3 on: July 31, 2014, 10:52:27 am »
Hello Guys,
your crypto-knowledge is wanted  :D

I am not exactly a crypto guy but I do have some solid background on this general topic.

At the moment i'm coding a program which should be able to keep the passwords of the users. Of course i don't want to save them in plain text, so i thought out sth.

The passwords will be saved AES256-CTR encrypted, but this is secondary. I want to ask you, what you think about the key and IV generation.
So first the Key.
The key is at first about 70 characters long and consist of computer-specific things like OS or Username. To get to the 256 bit length, this key get hashed, using SHA256. So at the moment the key is on every PC Unique. But in the next time i want to make more unique.

Now to the IV. The IV is 128bit long and consist out of parts of the key, because i don't want to save the IV anywhere.

And after that, the Password gets encrypted. What do you think about it? Are there any weak spots, which i didn't care about?

My 2 Cent on this

* as you state above you are effectively binding the password not to a user but to a combination of user & computer which is not really a good idea (only in very rare cases) and you seem to have understood this too as you want to make the approach more general in the future.

* the way you are setting up the encryption of the password is in fact weakening security as you base it on very "easy to guess" and "easy to achieve" parameters

* you are trying to leverage on this by including an SHA on the key but in fact this does not help

* you could get rid of all the above mentioned issues by simply applying one of the tested and proven (as far as things can be said now with NSA influencing security functions) hash functions just like SHA256 or others (choice is up to you) to the password and store the result. This is the way things are handled in nearly all implementations that address the same issue

Unless you have a very specific reason for not following this approach I can give no better Response. On a more genéral not I can say that a good way of thinking when working on security issues is the following

* if I would disclose the method I used to get security could somebody then crack my security system easily?

If the answer to the above question is "No" then you are probably on a good track - if the answer is "Yes" you are definitely on the wrong track
« Last Edit: July 31, 2014, 11:01:25 am by MathMan »

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: AES Encryption
« Reply #4 on: July 31, 2014, 11:21:31 am »

* you could get rid of all the above mentioned issues by simply applying one of the tested and proven (as far as things can be said now with NSA influencing security functions) hash functions just like SHA256 or others (choice is up to you) to the password and store the result.
The above although a lot better than the original question is not the best, read the link I provided if you are not interesting in reading all that at least read this http://throwingfire.com/storing-passwords-securely/#notpasswordhashes
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

MathMan

  • Sr. Member
  • ****
  • Posts: 325
Re: AES Encryption
« Reply #5 on: July 31, 2014, 02:05:53 pm »

* you could get rid of all the above mentioned issues by simply applying one of the tested and proven (as far as things can be said now with NSA influencing security functions) hash functions just like SHA256 or others (choice is up to you) to the password and store the result.
The above although a lot better than the original question is not the best, read the link I provided if you are not interesting in reading all that at least read this http://throwingfire.com/storing-passwords-securely/#notpasswordhashes

I am acutely aware of salting and peppering - I just consider the point from a different perspective. The dismissal of pure cryptographic hashes for password storage systems boils down to the point that the password provided by a user (when he creates it) is weak so hashes can be precomputed in abundance and then tested. Therefore the user provided password has to be enhanced. Salting relies on the random number generator and we have recently learned that these have been compromised / influenced by the NSA (and more so it seems than what they tried with hash functions). Peppering for me is security by obscurity because it relys on the fact that the attacker does not know the number of iterations (to put it simple). That the process of calculation is (or can be) slowed down is a nice side effect.

I'd rather force users to come up with strong passwords initially - and that i must confess was a point I forgot to mention in my initial response. Speed of attacks should anyway be countered with exponential backoff or hard tryout limits.

Don't get me wrong - I do see the point being made under the link you provided - I just happen to have a different philosophical stance to it.

BTW: I did start reading the link you provided in your first response. But after having read the first page I did'nt get how it was related to the topic and broke off ...

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: AES Encryption
« Reply #6 on: July 31, 2014, 08:58:13 pm »
I am acutely aware of salting and peppering - I just consider the point from a different perspective. The dismissal of pure cryptographic hashes for password storage systems boils down to the point that the password provided by a user (when he creates it) is weak so hashes can be precomputed in abundance and then tested. Therefore the user provided password has to be enhanced. Salting relies on the random number generator and we have recently learned that these have been compromised / influenced by the NSA (and more so it seems than what they tried with hash functions). Peppering for me is security by obscurity because it relys on the fact that the attacker does not know the number of iterations (to put it simple). That the process of calculation is (or can be) slowed down is a nice side effect.

You have that backwards, the primary goal of those none password safe hashes is to make it slower to guess making it to time costly. Salting is just one if the methods used to make a password harder to guess and in this case it is included in the hash it self if  I remember correctly.

As for the NSA "compromising / influencing" what ever, is just an assumption and there is no proof so it would be best stay out of any serious talk.

I'd rather force users to come up with strong passwords initially - and that i must confess was a point I forgot to mention in my initial response. Speed of attacks should anyway be countered with exponential backoff or hard tryout limits.

that is the wrong attitude you have to make the end users life easier at all costs not harder there are various techniques eg don't use passwords use passphrase or use a cryptographic hash for the encrypting password making easy for the end to has passwords as easy as a three letter password or four digit pin.

And that is the ultimate goal of encryption / cryptography.

Don't get me wrong - I do see the point being made under the link you provided - I just happen to have a different philosophical stance to it.

Its good to have those if they act as a leverage for knowledge and research if it used to ignore facts and tangible results then they need to be reassessed. In this case the linked in paper describes specific tangible results until we can produce an other technique with similar or better results then it is best to use what we have.
 
BTW: I did start reading the link you provided in your first response. But after having read the first page I did'nt get how it was related to the topic and broke off ...

Yeah all forum threads have a noise ratio that you need to be aware off.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

MathMan

  • Sr. Member
  • ****
  • Posts: 325
Re: AES Encryption
« Reply #7 on: August 01, 2014, 01:36:06 am »
I am acutely aware of salting and peppering - I just consider the point from a different perspective. The dismissal of pure cryptographic hashes for password storage systems boils down to the point that the password provided by a user (when he creates it) is weak so hashes can be precomputed in abundance and then tested. Therefore the user provided password has to be enhanced. Salting relies on the random number generator and we have recently learned that these have been compromised / influenced by the NSA (and more so it seems than what they tried with hash functions). Peppering for me is security by obscurity because it relys on the fact that the attacker does not know the number of iterations (to put it simple). That the process of calculation is (or can be) slowed down is a nice side effect.

You have that backwards, the primary goal of those none password safe hashes is to make it slower to guess making it to time costly. Salting is just one if the methods used to make a password harder to guess and in this case it is included in the hash it self if  I remember correctly.

Regarding peppering pls. see my former statement. If one discloses the number of rounds applied then the system is as secure (or insecure) as before - it just takes a bit more computing power to calculate. Beside that there is the point that if you do too many rounds on some algorithms the entropy tends to decrease - in effect decreasing the security of the final result (also stated in the link you provided as a caveat for system design iirc). On salting I already said that I do see the point of making life easier for end users. More on that later.

As for the NSA "compromising / influencing" what ever, is just an assumption and there is no proof so it would be best stay out of any serious talk.

OK - I should have more generally state "intelligence agencies" as I ment "NSA" only exemplaric. Sorry for that and matter closed from my side.

I'd rather force users to come up with strong passwords initially - and that i must confess was a point I forgot to mention in my initial response. Speed of attacks should anyway be countered with exponential backoff or hard tryout limits.

that is the wrong attitude you have to make the end users life easier at all costs not harder there are various techniques eg don't use passwords use passphrase or use a cryptographic hash for the encrypting password making easy for the end to has passwords as easy as a three letter password or four digit pin.

As said above I do see the point of making life easier for end users. However I do think that end users should understand what they are doing and if things are made too easy then users mostly forget about the implications. And things have the nasty tendency to come back and bite you. In the specific case I would ask the user to provide a strong password, tell him how this should look like and how to work with it. If he then does not provide one - e.g. he can not remember complicated ones, doesn't understand the importance, etc. - I can still enhance it by salting. But even then I would tell him what I did.

And that is the ultimate goal of encryption / cryptography.

Here I tend to disagree. The ultimate goal of cryptography is "information security, data integrity, authentication, and non-repudiation". What you described is (or should be) the ultimate goal of every good user interface and system design. And I totally subscribe to that within the limits I stated above.

Don't get me wrong - I do see the point being made under the link you provided - I just happen to have a different philosophical stance to it.

Its good to have those if they act as a leverage for knowledge and research if it used to ignore facts and tangible results then they need to be reassessed. In this case the linked in paper describes specific tangible results until we can produce an other technique with similar or better results then it is best to use what we have.

Yes - and I constantly work on doing so. In my opinion it is just not that simple when security systems are concerned.
« Last Edit: August 01, 2014, 01:38:14 am by MathMan »

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: AES Encryption
« Reply #8 on: August 01, 2014, 07:18:49 am »
Regarding peppering pls. see my former statement. If one discloses the number of rounds applied then the system is as secure (or insecure) as before - it just takes a bit more computing power to calculate. Beside that there is the point that if you do too many rounds on some algorithms the entropy tends to decrease - in effect decreasing the security of the final result (also stated in the link you provided as a caveat for system design iirc). On salting I already said that I do see the point of making life easier for end users. More on that later.

well read up on bcrypt please, as far as I remember, and it has been a few years I looked at the details so I might be wrong, the bcrypt saves the number of iterations and the salt used with the hash.

Yes it is going to be over powered some time in the future, when that time comes, I might change my policy to change passwords daily or even weekly from once every three or four months that is now and I'll still be secure.

The bottom line is that it is not as easy to overpower as you seem to think try it for your self and see.

OK - I should have more generally state "intelligence agencies" as I ment "NSA" only exemplaric. Sorry for that and matter closed from my side.


I know, but spreading rumors doesn't serve any one. I do not mind reading any evidence or facts that you might have though.

As said above I do see the point of making life easier for end users. However I do think that end users should understand what they are doing and if things are made too easy then users mostly forget about the implications.

Actually eradication of implication knowledge is one of the things that makes a product easier to use. So yeah that is what all products should strive for. Educating users costs to much, making sure that anyone can use a product is less expensive (fool proof products).


And things have the nasty tendency to come back and bite you. In the specific case I would ask the user to provide a strong password, tell him how this should look like and how to work with it. If he then does not provide one - e.g. he can not remember complicated ones, doesn't understand the importance, etc. - I can still enhance it by salting. But even then I would tell him what I did.

You do know that for the last 20 years or so the weak link in security is the user, right? Doesn't matter how much you can educate them any daily activity becomes a burden the more difficult an activity is the more chances it has to be dropped or by passed. Telling a user what you did or how the password system works is outside your obligations, instead of spending time educating people, that should know nothing about encryption password and its implications, it would be best to spend that time to make sure that even if the user fails, the system will not be compromised. You can for example give out only daily passwords, which after the work hours the password/pin or what ever it is, is no longer valid, give out cards as extra precaution (eg the credit/debit cards and pin), cards that can have the user name or password embedded (or both) and never leave the shop (something like the punch cards for time tracking) etc. What ever you do the user/people must be cut out the authentication process as much as possible that is why bio sensors where invented in the first place.

So, you are handling wrong in my opinion but that is outside the scope of this thread.


And that is the ultimate goal of encryption / cryptography.

Here I tend to disagree. The ultimate goal of cryptography is "information security, data integrity, authentication, and non-repudiation".

You have to protect the data for a specific time after which it makes no sense to protect them, for example protecting a credit card number after the card's expiration date.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

 

TinyPortal © 2005-2018