Tag Info

New answers tagged

1

The "mathematical proof" is you can choose N arbitrarily: t(bcrypt) * (2^N) >> t(sha) The final hash is all about avoiding collisions, so you're safe so long as hash >> password The salt is all about avoiding rainbow tables, so you're safe so long as (rainbow table size) * (salt) >> (attacker storage space)


5

Correct. As explained in that article the torrents use the BitTorrent protocol to share Sony's stolen data. Each piece that is downloaded via a seed is linked with an index into the file, and the hash of that portion is checked and verified. However, I don't believe its this hash that they are referring to in that article. Below I'll describe the process ...


8

The amount of human effort which has gone into computing each of those SHA-1 hashes found in Git is significant. And that means the number of hashes computed that way is fairly limited. If you want to find collisions, you need zero human effort per hash and very little computer time spend on each hash. Bitcoin might be the only system with enough computing ...


12

You could probably compute your own SHA1 hashes quicker from small arbitrary texts than that you harvest the hashes that someone else computed. But there's a lot of possible SHA1 digests, like a few for each atom in the universe and still some left. That illustrates the challenge if you want to keep a list of all known digests and search that list.


48

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 ...


0

The general situation looks like this: A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date). These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when ...


0

Regarding CRLs: CRLs are issued regularly. They don't need -- nor should they have -- long durations between updates. They are regularly reissued. (I just checked Facebooks certificate and they use http://crl3.digicert.com/ca3-g29.crl -- This CRL lists 7 days as the maximum time until the next update.) So you can just sign them with the signature of your ...


1

I have the following in my nginx /etc/nginx/perfect-forward-secrecy.conf, which gives me an A grade on SSL labs. Your certificate should be SHA256 though. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 ...


1

The Mozilla Server Side TLS guide you linked to is an excellent resource to follow for ciphersuite choices. Ciphersuite choices will change as new vulnerabilities in TLS emerge and Mozilla seems to do a good job in keeping up-to-date with recommendations. AES-128 is generally preferred because people think bigger is better. Both AES-128 and AES-256 are ...


0

Comodo recommendation is: ssl_ciphers ...


12

Nope Generally speaking: No. Hashing is not encryption. Hashing is not reversible. At all. It always generates a fixed length output. So with an output fixed to say 32 characters, and an input of 33 characters, there is no possible way to reverse this. The information of that one character is irretrievably lost. -- And along with it all other characters. ...


1

(Edit 2014-11-25: Reworded flushed out to phased out.) Short answer: From what I can tell, they will be gracefully phased out, not flushed out. (At least by Microsoft.) The old SHA1 root certs will expire regularly and Microsoft will no longer accept NEW SHA1-roots starting 2016. The old ones will stay in I guess, since they were compliant to the guidelines ...



Top 50 recent answers are included