Tag Info

Hot answers tagged

24

The SHA-3 hash competition was an open process by which the NIST defined a new standard hash function (standard for US federal usages, but things are such that this will probably become a worldwide de facto standard). The process was initiated in 2007. At that time, a number of weaknesses and attacks had been found on the predecessors of the SHA-2 functions ...


9

No. It'd be trivial for them to just take each part and bruteforce it, even for strong passwords. You're falling into the same problem as NTLM did in the early days, where a long password ends up being two really short passwords which are easy to bruteforce independently. Instead of having to crack one 10 character password (assuming a-z 0-9 that's a ...


7

There is no objective, systematic and consistent notion of what is a "round". Each algorithm specification defines things its own way. MD5 is described as first padding and then splitting its input into 512-bit blocks. Then, as the RFC puts it, there are four rounds where each round happens to be a sequence of 16 very similar operations. So we could say ...


5

Hash functions typically work by performing a single operation over and over. Each time through is called a "round". It's a bit like stirring a pot: you can't expect to thoroughly mix anything with just one turn of the spoon. But stir long enough and the original state of the ingredents can no longer be determined. Here's an example of a round of SHA-1. A ...


5

I'd go for the in-built Rfc2898DeriveBytes, with a high number of iterations - the higher the number the better, but I'd recommend 5000 as an absolute minimum. SHA1 is considered broken for some uses, but not in the way it's used in PBKDF2, and probably won't ever be within the lifetime of your product. Implementing your own PBKDF2 with SHA512 shouldn't be ...


4

Splitting the password is bad. Designing your own password hashing mechanism is not good, either. It is fine for learning purposes, but for production, this is a no-go, because you cannot know whether you did things right or not. It is a generic and all-encompassing flaw of homemade cryptography. Of all cryptography, really; but, at least, with public ...


4

There's at least one usage for which SHA-2 is seemingly better than SHA-3 and that's key stretching. SHA-3 was designed to be very efficient in hardware but is relatively slow in software. SHA-3 takes about double the time compared to SHA-2 to run in software and about a quarter of the time to run in hardware. Since SHA-3 takes double the time to run in ...


4

On the 2nd of October NIST decided what algorithm was going to be used to perform hashing. This was the Keccak algorithm. The Keccak algorithm is based on the hermetic sponge strategy. It's the new standard algorithm. We use standards to make have better compatibility. Keccak was designed by Guido Bertoni, Joan Daemen (one of the creators of AES), ...


4

The purpose of a salt is not to make computing the hash slower, it's to prevent rainbow tables from being useful. A single iteration of SHA512 is way too fast to be useful against bruteforcing attacks. On a decent GPU, you can do ~100M hashes/sec (new link) with SHA512. Multiply this for systems with multiple GPUs. With a slow KDF such as bcrypt, you can ...


4

Recomputing secret from SHA-1(secret || suffix1) (for any known value of suffix) would constitute a preimage attack. No preimage attack faster than luck is currently known for SHA-1 ("luck" works in average effort 2160 for SHA-1, i.e. totally infeasible). You won't get the secret value. However, if your goal is to compute SHA-1(secret || suffix2) then that ...


4

Personally, I would go ahead and use BCrypt. The algorithm may not be NIST-listed, but it's been around long enough (13 years now, and the Blowfish cipher itself almost 20) that I'd trust it. By comparison, MD5 was shown to be vulnerable a mere 5 years after its introduction and was considered completely broken in 18 years. The only known attack on the ...


4

Lets get some ground rules out of the way. SHA512 isn't an encryption function, its a hash function. PBKDF2 (Assuming you are using the newer 2nd variant...) isn't a hash function or an encryption function, its a way of using a hash function and is commonly used to generate the key for an block cipher or stream cipher. In most situations I don't think ...


3

First of, a hash function has an input: you hash something. GUID (actually UUID) don't have any input. To generate "unique identifiers" with a hash function, you just don't use a hash function; you have to define what you are actually hashing. There are several standard methods for generating UUID; all these methods aim at achieving "uniqueness" of the ...


3

Possibly, but given their size - much more likely to download a generation tool and a word pattern list. Rainbow tables are a carefully comprised collection of dictionary words and probable combinations in order to save on space. A rainbow table sufficient for alphanumerical passwords of up to 9 characters is 864 GB in size. A rainbow table for this level ...


2

The text means "simple" by opposition to what was used in the older traditional DES-based crypt() where the salt was a 12-bit value, represented as exactly two characters in a restricted set. Ulrich Drepper wants to say that his creation is less picky and can take as salt any sequence of up to 16 bytes. Though the hashing function itself can work with any ...


2

Bcrypt is marginally "better" than PBKDF2. However, PBKDF2 is already quite fine: used properly, it ceases to be the weakest point in your system. Remember that the point of the iterations in PBKDF2 is to make the password hashing slow for the attacker. Unfortunately, it makes it slow for you, too. You thus need to avoid making it unduly slow for you. In ...


2

This corresponds to an RSA PKCS#1 signature with SHA384 hash. This means that the data is hashed using SHA384, and that hash is signed with the RSA private key from a PKCS#1 certificate. In terms of securing data in a database, this would be pretty unusual. However, it could be used to ensure that data entered into the database was generated by the owner of ...


2

As the llama says, there is little point in pre-hashing the password on the client side: SSL protects you. Of course this assumes that you use SSL for all communications; if you do not, then you already have much bigger problems that you should tackle first. If an attacker sees "SHA-512(password + long_string)" then the attacker can run an offline ...


1

In SSL there are two areas where SHA-1 or SHA-256 may be used: in the specific entrails of the protocol itself, for the internal "PRF" (a function used during the handshake) and for protecting the integrity of subsequent data exchanges; as part of the signature over the server's certificate, and its CA certificate, and so on. SSL 3.0, TLS 1.0 and TLS 1.1 ...



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