Tag Info

Hot answers tagged

20

This isn't necessarily unexpected. 32-bit platforms vs 64-bit platforms can make a significant difference, as well as the amount of data you're hashing. $ uname -m x86_64 $ openssl speed sha256 sha512 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 ...


16

SHA-512 has 25% more rounds than SHA-256. On a 64-bit processor each round takes the same amount of operations, yet can process double the data per round, because the instructions process 64-bit words instead of 32-bit words. Therefore, 2 / 1.25 = 1.6, which is how much faster SHA-512 can be under optimal conditions. Of course there is memory overhead, ...


7

SHA-512 (and SHA-384) is usually faster on 64-bit platforms, and SHA-256 is usually faster on 32-bit platforms.


5

Collision attacks are attacks where success is obtained when two values obtained by some process are identical. The term is often used in the context of hashes, since collision-resistance is one of their desirable property. Birthday attacks are collision attacks that work by the effect of chance, with the colliding values obtained by some roughly random ...


5

You can't say SHA-2 has a security level of half its hash length without any given context. 128 bit against what type of attack? What is the attacker trying to do? Perform a collision? Ok yes it has 128 bit against collisions. Perform a preimage? Nope it has 256 bit security against preimage attacks. Any algorithm is considered n bit strength if the ...


4

The result of SHA-256 of an empty string is: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Accordingly to this and this


3

Here is a "backdoored" hash function: Let $p = 2q + 1$ be a big prime of length $2048$ bits, such that $q$ is also prime. Let $a$ be an integer of order $q$ modulo $p$, i.e. $a \neq 1$ but $a^q = 1 \pmod p$; it can be shown that $a = 4$ is always a valid solution. Let $s$ be a (secret) integer between $1$ and $q-1$, and let $b = a^s \pmod p$. Then define ...


3

TL;DR: You put less of a burden an any attacker trying to brute-force this. And please note: Implementing PBKDF2 shouldn't be much harder than implementing your approach. Now let's head over to the explanation why "your" scheme is really bad for password-hashing. The scheme you propose is that each try cost you exactly two hash-function evaluations. One ...


2

If you have two prefixes, say $p_1$ and $p_2$ assuming a well designed hash function, this will give you two lists of possible candidates $L_1,L_2$ each of size roughly $2^{24}.$ The correct value is in both of these lists. It is unlikely to also have spurious candidates since assuming uniformity o relevant variables and fixing, say the list $L_1$, the ...


2

You cannot; most (symmetric) encryption routines create output that is indistinguishable from random. This is however more likely to be the output of a password hash. The only thing you can say is that the result is 24 bytes. That 24 bytes hopefully contains a fully random salt (mostly 8 bytes) and a hash or password hash. In that case it's probably MD5 as ...


2

Designing such a challenge is Impossible. If we assume that having a connection is equal to being able to exchange any piece of knowledge at any given time then the proof of impossibility of such challenge is as follows: Proof. First assume that there is such a challenge and Alice is capable of querying such a challenge to correctly determine whether the ...


1

Yes, this could be done. It would be easy to implement and use this in a way that would be horribly insecure (e.g. with too short a passphrase, and not enough key stretching), but if used carefully, it could even be secure. Basically, what you'd do would be: Generate a secure passphrase, e.g. a sequence of randomly chosen words. This can be done ...


1

The speed of individual algorithms strongly depends on their implementation. This goes for both hashing algorithms as well as encryption algorithms. This quickly becomes clear if you take a look at efforts like “eBACS: ECRYPT Benchmarking of Cryptographic Systems” and the results presented. Also, you should not ignore that some algorithms have specifically ...


1

2 candidates are enough that you can (with high probability) uniquely identify the correct secret. An attacker would still have to enumerate all $2^{56}$ possible values for the secret -- or, on average, about $2^{55}$ values -- to find the right one. But if the attacker has 2 candidates, then this is enough information that the attacker can recognize when ...


1

Hash the original text, store the hash along with other auxiliary data. Check decrypted text against the hash. This will check the overall integrety of the process, not just the use of the correct key.


1

Let's shortly recall, how HMAC looks like: $HMAC_K(M):=H((K\oplus opad) || H((K \oplus ipad) || M))$ As you may observe here, the calculation of the outer hash is fully independant of the message. So the standard approach into implenting "update" functionality is to store the key and go as follows: Init(Key): Store the Key in K Init two Hash-function ...


1

Usually a cryptographic transformation can mean anything. It is just a cryptographic function whose output is based on the input, $K$ and $R$ in this case. You could have a $MAC(K, R)$ where the transformation is a message authentication code or MAC for instance. A MAC also takes a key and a message, but its purpose is rather different. So $K\{R\}$ is a ...


1

This is a perfect job for a Key Based Key Derivation Function or KBKDF. Generate two keys from the input (salt and password). One is stored directly in front of the ciphertext and one is used as encryption key. Because the KBKDF is based on PRF it cannot be reverted, so the keys are not related as far as an attacker is concerned. Currently the best KDF is ...



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