# Tag Info

8

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...

6

From looking at the source or 7zip that seems to be the case. The format has a place for a salt, as SEJPM's link shows. It is mixed into the homebrewn iterated SHA-256 hash before the key. The 7zip decoder even seems to support salts. However, the encoder never uses a salt. Oddly there is even code for generating a random 4-byte salt, but it is commented ...

5

I want to make it harder to decrypt AES I send. Fundamentally, the thing you are trying to do is completely unnecessary. If AES does ever become broken, the scenarios in which this makes any measurable difference are exceedingly unlikely. If AES isn't broken, then doing this was wasted effort in the first place. There is zero plausible reason why your ...

5

Answering your question If an attacker have access to a copy of my users database table containing each salt and the related salted password, I can't understand how a CSPRNG would be more secure than a SHA12 hashed UUID. Can someone elaborate? I’m not sure if you only have read the question “Cryptographically Secure Pseudo-Random Number Generator in Qt/...

5

Yes. They provide different things. The reason you hash a password is so you compare it later on without ever exposing the plaintext. A salt is used to make a large collection of hashes harder to bruteforce. Encrypting a hash does nothing to make the hash harder to bruteforce. If you're compromised to the point your hashes are leaked, there is a good ...

5

You are right that if it costs Alice & Bob effort $N$ to agree on a key in this way, then it costs Eve only effort $N^2$ to find it. So the protocol is not secure in the standard sense, and probably not very useful. (Maybe in some highly constrained situation with very short-lived keys?) More generally, this purports to be a key agreement protocol whose ...

5

512 bits is overkill for even global uniqueness. 256 bits should be enough, with a good random number generator: even if every person on earth generated one every nanosecond, it would take a million million years to reach the birthday bound. However, I agree that global uniqueness is a good idea. If anyone anywhere uses the same salt and password hash (or ...

4

It is possible to reverse the birthday bound calculation. You can get an easily computable approximation using the expected number of collisions: If you had random $n$-bit salts, after $k$ values you would expect $2^{-n}\binom{k}{2}$ collisions. If the collisions are rare, they are mostly single collisions, so there are approximately $u = k-2^{1-n}\binom{k}{... 4 Yes! I'd recommend at least 64 bits, but that's only because powers of two are convenient and space is cheap. Furthermore, usually a salt of the block size of the hash you're using is usually best, because salting at all will almost always involve an extra block, so why not fill it up given that there will be no performance impact? But once again, yes, you'... 4 There's absolutely zero need to have the token tied to the user's email address. Just add a column in the database for the token, generate the token randomly, and send it out to the user. If you want to go one step further, send the user the token, but only store$H(token)$in the database, where$H$is a sound cryptographic hash function of your choosing. 3 For example, someone suggested improving UNIX authentication by defining 3 different passwords for a user that are stored in the shadow file. All three passwords are stored with the same salt value. When a user wants to authenticate to some system, he must provide in the i attempt to login, the i mod 3 password. For example, in the first attempt he will ... 3 From a cryptographic standpoint a MAC would be perfect (e.g. HMAC-SHA256(strong secret key, email)). As long as no-one knows your secret key it is infeasible to find a token for another mail. One thing you will probably have to handle is: What happens when someone changes their email? What if someone resubmits the same form? Should the token be invalidated ... 3 The answer is yes. There is no problem with sending the IV in the clear. So, this is fine. Likewise, the salt is not there to add entropy so this is also fine. Having said that, I understand from the code that the application is not using a uniformly distributed (and so high entropy) key. This is a problem and very bad, since it is easy to carry out a brute-... 3 Since this is still open and the issue keeps coming up: TLDR: There are lots of things in OpenSSL that implement standards including AES, but the key derivation part of enc is partly nonstandard First, OpenSSL has several commandline operations it calls commands (although they usually aren't separate programs, as typical commands are on Unix), and a whole ... 2 Short answer: Yes, you're right. 2 First, good password hashing functions like PBKDF2 and scrypt usually take the password and salt as separate parameters, meaning the user does not have to worry about this. However, with some algorithms they do and in any case the theoretical question is important. Some of those methods you mention are clearly worse than others: Binary OR would be ... 2 In cryptography an Initialisation Vector or IV is an input of fixed size required to randomize the output of a cryptographic primitive. It is not meant to be secret, so there is not problem in make it available to the attacker after the encryption. The crucial point about the IV is its uniqueness and, for some mode of operation, its unpredictability. So, if ... 2 I'm no security expert but I'll take a stab at this since it hasn't been answered. Also, I'm answering as if you're asking about a Rainbow table or Dictionary attack for preimage and second-premiage attacks. Preimage being the rainbow table attack and second-preimage relating to getting similar encrypted values (cipher text) from the same password. If ... 2 No, wrapping the data key set seems a good idea to me. It's pretty standard and should even work with e.g. hardware modules. Note that your old ciphertext would still rely on the security of your old secret (password) when you choose this scheme! If$Enckey$is ever guessed it can be confirmed by decrypting (the first part of) your ciphertext. There is a ... 2 "I'm using [AES] in CBC mode, but the implementation doesn't add the randomness I want, the same message when encrypted looks the same." This is a problem. If you were using CBC mode correctly (i.e. with a random IV), then encrypting the same message twice would produce completely different ciphertext. Since you're not using CBC mode in the way it's ... 1 This looks like a (homework) assignment as the parameters are artificially small and the method is highly unconventional as opposed to the standard "You want the attacker to do more work?" - "Just increase the work parameter!". Because of this I'll give you some hints on how to solve this. Increase the size of the salt from 12 bits to 24 bits. You ... 1 I ran into a situation with a similar requirement, and here's the idea I came up with: We don't use a conventional 'salted hash', instead to encode a user's password, we first hash it (optionally with the user's id, but without a salt) to form a value$h$, and then you select a random Elliptic Curve point$X$, you compute the point$Y = hX$(where$hX\$ is ...

1

In Password-Based Encryption (PBE) we use a randomly generated (and hopefully unique) salt to prevent dictionary attacks on the key generated from a password. Every "user" in a system should at least have a different salt. Since key derivations can be made arbitrarily hard just by increasing the iteration count, we can have, let's say, a key derivation ...

1

Your setup is secure. However it is largely "unneccessarily" secure. First the generation method: You're using the RNG-CSP which is (I guess) Microsoft's software interface to the Windows secure PRNG, so this is fine. Now for your tokens: You're restricting the character set, which reduces the possible entropy per byte, but is fine if you're in a Web-...

1

No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation ...

1

I think it's awesome that you are building your own encryption-decryption algorithm. You will learn a lot about crypto that way. So far, everyone who builds a crypto encryption-decryption algorithm builds something horrifically flawed in one way or another -- very educational -- the first time. terminology If I understand your question correctly, you have ...

Only top voted, non community-wiki answers of a minimum length are eligible