4

I am encrypting files inside a device and store it. So I need to maintain the same key throughout the life cycle of the device. For key derivation I use EVP_bytestokey() of OpenSSL.

The problem in password based key derivation (PBKD) is that the attacker can guess the password if that password is from user. But in my case I am using some long system based number (not from user) as a passphrase. Is this a right way?

Does modifying the encryption key in my code (say like left shifting or right shifting the key) help in security?

How about storing the salt in the code (hard coding)?

StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
Rak
  • 431
  • 5
  • 13
  • Nomenclature: a system wide, hard coded, secret hash ingredient is more usually known as "[pepper](https://en.wikipedia.org/wiki/Pepper_(cryptography))". Is this what you mean? – StackzOfZtuff Jul 22 '15 at 11:57
  • @StackzOfZtuff yes. But I think it is better to use a dynamic one instead of hard coded pepper. – Rak Jul 23 '15 at 05:03

4 Answers4

2

The problem in password based key derivation (PBKD) is that the attacker can guess the password if that password is from user. But in my case I am using some long system based number (not from user) as a passphrase. Is this a right way?

A password is "a secret key that fits in the user's brain". The main attribute of a secret key is its secrecy, which is a measure of how much attackers don't know it. Generally speaking, attackers are (assumed to be) super-smart, so the only thing they do not know is pure randomness.

The main problem with passwords is that human brains are not good at storing randomness (they are also very poor at producing randomness). This is what makes passwords weak: attackers can try to find the password through "guessing", which basically means trying out all combinations of human-compatible randomness.

PBKDF2, like other password-hashing functions, is meant to make the weakness of passwords more tolerable, by making each guess more expensive (for both the attacker and the normal user).

If, in your application, the password is not really entered by a user but by a machine, then you can use a "password" with a lot of randomness (machines are much better than humans at remembering long sequences of random numbers), at which point password hashing may become quite useless.

Does modifying the encryption key in my code (say like left shifting or right shifting the key) help in security?

It helps about as much as dancing with a teapot on your head while chanting the glory of Huitzilopochtli will help you guess the next winning lottery numbers.

(If Huitzilopochtli is really amused by your ritual, he may grant you some benefits, but he is not really known for his sense of humour.)

How about storing the salt in the code (hard coding)?

The salt makes sense in conjunction with password hashing: it is one of the methods by which passwords (which are inherently weak, see above) can be tolerated. If your "passwords" are not really passwords, then password hashing and salt are irrelevant.

Conversely, when a salt is relevant, then its main and only point is never to be reused -- hardcoding the salt in the code does the exact opposite.

Thus, one can say that hardcoding a salt value is either a bad idea, or a very bad idea, depending on the context.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Ok. I am not going to hard code the salt. I will generate the salt dynamically. Since I am using different passphrase for each file reusing the salt for all files should not be a bad idea. Isn't it? – Rak Jul 22 '15 at 06:40
1

remember physical security is as important as logic, if your hardware is relatively secure (or heavy) and you are worried about the harddisk getting stolen and decrypted then use hardware information such as serial numbers (atleast 2 of them - which i believe you are already doing) this way the drive cannot be decrypted without being within the right hardware..

in regards to extra layers and salts, just ensure you obfuscate your encryption and decryption scripts and a hard coded salt should be fine.

I am not 100% on your scenario obviously, but depending how encryption, decryption etc works in your case depends on what a viable salt would be, if you can make the salt dynamic to each file specifically in someway this would mean that even if they stole the hardware and guessed 1 files salt they would not be able to decrypt the rest of the files.

I might be able to give you a few suggestions if I knew details of the scenario, but sometimes you shouldn't share some information (social engineering)

I hope this sparks some ideas.

TheHidden
  • 4,315
  • 3
  • 22
  • 40
  • How about long passphrase(say 32 bytes)? What is the vulnerability of attack? Is EVP_bytestokey() good to use? Btw using different salt is a good idea. – Rak Jul 21 '15 at 09:50
  • I have never used EVP before but researching it a bit it seems quiet good, 32 bytes will be enough 64 is better but 32 will still take a very long time to crack, throw in dynamic salt and you got near impossible for someone to crack your files in a life time. unless they have 3 wishes from a magic genie – TheHidden Jul 21 '15 at 10:52
  • Ya. But while decrypting the files also I should use the same salts. That is the problem. Otherwise I couild have used the dynamic salts. – Rak Jul 21 '15 at 11:48
  • depends on how you get the dynamic salts for example it could be the name of the file backwards? or the name of the file hashed turned into bytes and multiplied by X. a million ways to do things my friend :D – TheHidden Jul 21 '15 at 13:01
1

A KDF to strengthen the password is only needed if the password itself could be weak. The prime example is when a human has generated it.

A KDF will iterate the password hash a number of times. This means that an attacker that gains access to the password hashes will have to iterate each password guess that numbers of times, slowing their attack. This has the same effect as a strong password with no KDF. This is because the extra keyspace that a password with greater entropy would have can have extra hash iterations substituted to account for the time needed to break.

Therefore, a computer generated password does not need a KDF for key stretching because it can simply generate a key with enough strength on its own. Go for 128 bits of entropy if possible, generated by a cryptographically secure random number generator (CSPRNG).

Regarding salt - you don't need one. 128 bits would be enough to secure the password against hashing attacks intrinsically. Rainbow tables to cover the whole 128 bit keyspace would be unfeasibly large.

SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
0

When you say "long system based number", what do you mean, exactly? If the only input to your key generating function is a static constant stored on the machine, then your encryption will do nothing against an attacker who gains access to it. It will prevent them from lifting data and decrypting it on a different machine, though.

Generating a key based on a user-supplied password ensures that the attacker needs external information to extract data from the device. Of course, this means that the user has to pick a good password, but I'd argue that's smarter than storing the password on the machine itself! If the password is well-chosen (e.g. a long passphrase), the attacker will have no chance of guessing it in a thousand years.

Your choice of key source will depend on your use case. You might even go for a combination of the two (e.g. Windows offers an encryption service that relies on a security chip in the hardware as well as the user's password).

Salts are used to make hashed secrets harder to attack with pre-computed hash tables. The most common application is in password storage. If an attacker can prepare a large list of common passwords and their hashes, then they can easily look up password hashes to find cleartext equivalents. Appending a salt to the password and hashing the result makes this much more challenging.

I don't see how salts are applicable here, though. You're encrypting a large amount of data, not hashing it. There's no way an attacker is going to build a table with every possible file and every possible encrypted version of it.

Also...salts are not secrets, since they need to be available to access secrets! You might be able to obfuscate the salts (using filenames, for example), but let us remember the golden rule of security:

Security through obscurity is not security. Assume the attacker knows everything except the key.

This applies to some of the other things you brought up as well - randomly messing with cryptographic functions will do you no good.

Build a robust system, not a shoddy one.

etherealflux
  • 780
  • 4
  • 12
  • I like the points you make, though maybe in my answer "salt" was not the right word, I think using hardware serial numbers as well as an extra value (which I can only logically describe as a salt or extra key) which is specific to each file. Also in regards to obscurity is not security, I would agree on some levels but the point of security is to make it cost more to obtain the goods than the goods are worth, if obscurity adds to it then its security. Maybe a good approach to take is keeping the key away from the lock and storing the key on a remote location? – TheHidden Jul 21 '15 at 15:35
  • I dunno' if a little extra obscurity would be enough to make your device a non-target. Trying to brute force a good encryption scheme is functionally impossible (barring the solving of NP-hard problems). As for keeping the key remote, it's a good idea! It's the basis of hardware security dongles, for example. – etherealflux Jul 21 '15 at 15:41