Just to cite wikipedia: http://en.wikipedia.org/wiki/SHA-2:
The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.
So yes, SHA-2 is a range of hash functions and includes SHA-256.
This may be a case of "do what I say, not what I do". Note that Chrome complains about use of SHA-1 for signing certificates whose validity extends beyond the end of year 2015. In this case, Google's certificate is short-lived (right now, the certificate they use was issued on June 3rd, 2015, and will expire on August 31st, 2015) and thus evades Chrome's ...
Actually this is a good way to protect the otherwise unsecurely stored passwords. There is one weak point in this scheme though, which can be overcome easily in marking old hashes, so I would prefer this solution:
correctPassword = bcrypt_verify(sha1(password), storedHash)
correctPassword = bcrypt_verify(password, ...
It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on.
The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm.
What does that mean?
It means the connection is encrypted and a passive eavesdropper can still not listen in. But a ...
My question is: Does every hash value H have a value V?
For example, given md5 hash value f2c057ed1807c5e4227737e32cdb8669 (totally random), can we find what it was from?
These are actually two very different questions: whether there is an input for each output, and whether we can find an input for each output.
For your first question: we do not know. ...
I suppose you "use sha1sum" in the following context: you distribute some software packages, and you want users to be able to check that what they downloaded is the correct package, down to the last bit. This assumes that you have a way to convey the hash value (computed with SHA-1) in an "unalterable" way (e.g. as part of a Web page which is served over ...
Is Git crowdsourcing the production of SHA-1 preimages? Not to any meaningful degree.
Github doesn't say how many commits it's tracking, but it's probably not more than a few billion. For comparison, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible SHA-1 hashes, so the odds of finding a plaintext matching an arbitrary ...
Currently, given the specific collision method used, the impact is quite limited. In particular, this method does not allow for an attacker to generate a collision with an existing file, where a SHA-1 hash has been provided. It wouldn't be possible, for example, to use this method to generate a malicious executable file which matched the signature provided ...
Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent.
SHA512 is a one-way compression function, so you can't deduce the password from ...
From a usability standpoint, it's awful. You need to generate a hash each time you want to log in. Even using a password manager to look up truly random strings would be less work.
From a security perspective, you have combined the problems of hashing client-side and using a password pattern:
Yes, using a password hash on the client-side means that your ...
The idea of a large number of iterations is not to be part of the secret, but to take more time.
Having a database with a large number of passwords means someone will have a weak password, and it's trivial to test the dictionary of worst 100k passwords in minutes, no matter if you are using 200k iterations, or 153 as you are using. A dedicated password ...
Short answer: collisions don't matter for password verification. The length of the input is irrelevant.
I understand that md5 and sha512, etc... are insecure because they can have collisions.
No, this is wrong. MD5 and SHA-1 are insecure because it is possible in practice to find collisions.
SHA-512 and the other SHA2 variants (SHA-256, SHA-384, etc.) have ...
Yes. The protocol itself is no longer secure, as cracking the initial MS-CHAPv2 authentication can be reduced to the difficulty of cracking a single DES 56-bit key, which with current computers can be brute-forced in a very short time (making a strong password largely irrelevant to the security of PPTP as the entire 56-bit keyspace can be searched within ...
The SHA-2 family consists of multiple closely related hash functions. It is essentially a single algorithm in which a few minor parameters are different among the variants.
The initial spec covered four variants with output sizes of 224, 256, 384 and 512 bits.
The most significant difference between the variants is that some are designed for 32 bit ...
The definition of a cryptographic hash function includes resistance to preimages: given h(x), it should be infeasible to recover x. A hash function being "reversible" is the exact opposite of that property. Therefore, you can have no more a "reversible hash function" than you can have a fish allergic to water.
Possibly you might want a hash function which, ...
First, there's Kerckhoffs's principle which is always desirable:
A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
where in this case the password is the key. So its not a goal to keep the cryptosystem secret.
Second, you are wrong about those being md5 or sha512 hashes; the values stored in your /...
I'm not aware of any publicly known attack using collision in SHA-1, but MD5 collisions were probably used already 2010 within attacks. In 2012 it was discovered that a malware from the Flame attack had a valid signature from Microsoft, which was possible due to a MD5 collision attack. See http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-...
As others have said, technically the risk is small for a MiM attack. However this has a larger problem and implication.
Should I go ahead and enter my card details and pay for something on this site?
NO, YOU SHOULD NOT USE THIS SITE FOR A CARD TRANSACTION
The SSL issue is, as stated by others, relatively minor, however, using a SHA-1 hash means two ...
And it is longer than the input string, with 288bit instead of 256bit. So did we actually increased the entropy?
No, you did not increase the entropy.
In this context, "entropy" basically refers to the probability of any particular guess about the content or value being correct.
If I tell you that I have hashed a single lowercase US English letter's ASCII ...
First of all, MD5 is not an encryption algorithm. It is a hash function. Encryption generally implies decryption, which you cannot do with a hash function.
Who said MD5 is good or unbreakable? It is 'breakable'. The complexity of obtaining a collision for MD5 is around 2^64. This is the equivalent of an exhaustive key search of 64 bits, quite weak for ...
Nothing has changed in the industry. Qualys is now just highlighting what we already know.
It is to give you a reminder that you should move away from SHA-1. It's not generally considered a critical problem yet, but should be sorted as part of normal refresh/update cycles.
There is no contradiction. Linus himself said in that same talk:
If I have those 20 bytes, I can download a git repository from a
completely untrusted source and I can guarantee that they did not do
anything bad to it.
I'd interpret the "Git uses SHA-1 not for security" as "SHA-1 hasn't been added to git for security reasons, but for reliability ...
First of all, thank you for taking the time to determine how to do this correctly and improve security for your users!
Migrating password storage while taking legacy hashes into account is relatively common.
For your migration scenario, bcrypt(base64(sha1(password))) would be a reasonable balance. It avoids the null problem (important - you definitely don't ...
A root certificate is a self-signed certificate (by definition).
So how do you want to verify the signature of a root certificate? The root certificate is valid in itself, therefore you cannot verify it.
This is also the most problematic part of root certificates: they cannot be validated independently. If they are in the browser, then they are trusted.
FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password ...
Technically, not as stated. AES-256 requires a 256bit key. SHA-512 will output 512 bits so unless you chop off half of the digest it will not work.
A better solution is to use a standard and well tested key derivation function such as pbkdf2.
Don't roll your own crypto unless absolutely necessary. Use vetted constructions.
What the manual is referring to as rounds is probably better called iterations. While it is true that the SHA-2 function internally has a fixed number of rounds (64 or 80, depending on which hash is used), that is not what this manual is talking about. In order to make hashed passwords more secure, programs will often put the password through a KDF function ...
Re. Thomas' answer:
I just ran an SSL Labs scan on a Google.com server and it seems that the end entity cert is in fact SHA256withRSA. But the (single) intermediate is only SHA1withRSA. No idea why.
Yes, hashing it again with bcrypt is a good idea. Do note, though, that it will not give your login code more entropy, it will just make it take longer time to crack. So if it is really low entropy to begin with you might need a very high cost factor to make it unfeasible to crack.
On a side note, in general it is better to just hash with one good hash ...
The browser already contains a copy of the root cert. Thus, it doesn't need to verify it through its signature. Even if you broke SHA-1, you couldn't replace the root certificate that is already stored in the browser.