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 ...
Producing SHA-1 collisions is not that easy. It seems reasonable that the attack with has been described on SHA-1 really works with an average cost of 261, much faster than the generic birthday attack (which is in 280), but still quite difficult (doable, but expensive).
That being said, we do not really know what makes hash functions resistant (see for ...
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 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 ...
No. It's not just the length of the output. There are significant differences in their level of security against cryptanalytic attacks.
There are devastating collision attacks on MD5. (The Wikipedia article on MD5 has some details.) These attacks mean that MD5 provides essentially no security against collisions: it is easy to find collisions in MD5.
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, ...
Hash functions are deterministic: same input yields the same output. Any implementation of a given hash function, regardless of the language it is implemented in, must act the same.
However, note that hash functions take sequences of bits as input. When we "hash a string", we actually convert a sequence of characters into a sequence of bits, and then hash ...
For SSL, there is SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2.
In SSL 3.0, an internal Pseudorandom Function (PRF) is used to extend the shared secret (obtained from the key exchange mechanism) into symmetric keys for the subsequent symmetric encryption. This PRF always uses both MD5 and SHA-1.
In TLS 1.0 and TLS 1.1, the PRF is replaced by a new construction, ...
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 ...
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.
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'...
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.