Tag Info

New answers tagged hash

4

A one time pad (OTP) should by definition not have any patterns. An entropy source can have patterns, but an OTP by definition should consist of pure random bits. In general you can create something that is close to a true random number generator by applying a cryptographic hash function over the output of an entropy source. According to NIST you should ...

2

If your ints are unsigned then the code r = (r * 33) + (int)c and the fact that you're using 32-bit integers yield the equation $\;\;\;\; \text{new_r} \: \equiv \: (\text{old_r} \cdot 33) + \text{(int)}\hspace{.02 in}\text{c} \;\; \pmod{2^{32}} \;\;\;\;$. Since 33 is odd and $2^{32}$ is even, 33 is a unit mod $2^{32}$. $\:$ I used wolframalpha to determine ...

2

Am I on the right track with reversing DJB2 (can it be reversed?)? Is there some way of finding the remainder of a large number that has been modded by 232? You were on a right track to explain why it can't be easily inverted. Given an arbitrary $h_i$, every letter of the alphabet will give you another potential $h_{i-1}$ that the value was before that ...

1

What is the probability that both [Hu] = [Hmu] and [He] = [Hme]. In english, what is the chance that two different files can have identical hashes in both an unencrypted and encrypted form? Depends on whether they are "random" files or attacker controlled. MD5 is a 128-bit hash, so for two random files that differ the probability that they have the ...

4

Actually, the Merkle–Damgård construction also specifies a padding bit after the message. The length is there the ensure that a padded message cannot be the suffix of a different longer message. A collision at the prefix leads to a collision in both messages. With a padding bit, a singe byte message 0x30 vs a 2 byte message 0x30 0x00 are padded to 0x30 0x80 ...

2

Isn't it still possible to find two different inputs that will be padded to the same value and then deliver the same hash? Well, no, it isn't. Given a padded message (that is, padded by adding a 1 bit, and then as many 0 bits as needed to fill it out to a multiple of the internal block size), we can unambiguously recover the original message -- by ...

2

If there exists an encryption scheme, then there exists an encryption schemes such that one can easily modify a single ciphertext so that whether or not that modifies the decryption result depends in a predictable-and-useful way on what the plaintext message was, such as: The modified encryption operation outputs a zero concatenated with the original ...

2

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...

4

It has the disadvantages of any MAC-then-encrypt scheme, which I'm quoting from the linked answer below. In addition: It has the property that you need both a nonce and a hash, so for equivalent security it requires more message space. The nonce has to be random, so it requires strong random numbers for each message, unlike e.g. AES CTR + HMAC. Doesn't ...

1

I haven't seen much analysis on using ordinary hashes for content authentication. Can anyone can give me a pointer on whether this is safe? With good choice of primitives it is. Public key signatures use a hash function in a similar way to identify the message signed. However, where a MAC only needs what amounts to second preimage resistance, a hash ...

1

Assuming the hash is strong, you will not be able to find a preimage any more easily when you know multiple hashes (whether they use the same function or another). In fact, with some hashes you will be able to derive $H(S||K)$ from just $H(S)$ and $K$ (known as the length extension attack), so it can't give you more information. Unless the hash is broken, ...

6

PBKDF2 (as defined by RFC 2898) is a function of the form $$DK = \text{PBKDF2}(\text{PRF}, Password, Salt, c, dkLen)$$ In most practical use cases, the $\text{PRF}$ is $\text{HMAC}$ instantiated with a Merkle-Damgård hash function such as $\text{SHA-1}$. The time to compute $\text{PBKDF2}$ is roughly linear with the iteration parameter $c$, all other ...

5

Firstly, How much time will it take to crack PBKDF2 while using a 9 character password? and how do I calculate the cost? I'm not specifying any specific system or platform. If a brute force attack is made using the best ever super computer around how much time will it take to crack it? Unless the underlying PRF is broken, brute force and dictionary ...

3

GMAC is quite simply GCM mode where all data is supplied as AAD (or additional authenticated data), or as NIST SP 800-38D puts it: If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. If you don't have access to a cryptographic provider ...

3

The basic flaw is the same as indentified in this answer I linked in comments: If you know the plaintext for block $i$, you can derive the key for that block and then derive the rest of the keystream from that key. Thus, an attacker can simply make guesses on the message until they find one that allows them to decrypt the rest of the message. A better ...

2

Here is my take on your algorithm. I'll try to perform the known plaintext attack. Knowing the plaintext allows to recover the keystream (passphrase) by simply XORing it. This in turn reveals the value of hash(hash(text) XOR hash(password)) -- simply the first hash block, and the value of hash(text) is known (by virtue of KPA plus it is leaked by your ...

2

Depends on your security requirements. Basically it is OK to create a (slow!) stream cipher using a secure hash method, given that the password has a large enough security margin. But your code has at least the following issues: you leak enough information in the first block to regenerate the key stream from a known plaintext (thanks otus); you have to ...

2

By 'IHV', I assume you mean the Initial Hash Vector; that is, the state of the hash function before you start hashing. Well, if they aren't using the standard initial values (specified by the hash function definition), well, there isn't much you can do. The problem is that the compression function used by Merkle-Damgaard hash functions (such as MD5 or ...

3

I'm pretty sure that they store only the hash. They can detect that you didn't change enough characters in the following way: When you provide a new password, the system generates several passwords that similar to the new password, by changing some characters. Then it calculates the hash of each similar password and compares it to the last stored hash (or ...

2

When using PBKDF2, is there a practical upper limit to the iteration count above which we lose security? No. There is a limit above which you gain no security, but it isn't practical. It's on the order of $2^{128}$ iterations for PBKDF2-HMAC-SHA-2, or $2^{80}$ if you use SHA-1 as the HMAC hash. For an explanation, see the questions mikeazo linked in ...

3

My question is: does it add any security to add a random salt to the message you are validating with HMAC? This depends on what the HMAC is used for. If you use a key to sign more than one secret message, a salt will prevent an attacker from knowing whether two of them are equal. (Or brute forcing a message if the key is revealed...) It is more common ...

8

When only using one-way hashing, is it possible to tell the number of characters changed between the old and new password? No. If the hash function is strong, even a single bit change will give a completely different hash. The only way to tell how many characters differ between a particular unknown hash value and a known password would be an exhaustive ...

1

Is there any advantage – other than potential memory or speed performance reasons – of picking a state size different from 512? If, what would the advantage(s) be? Yes. With 256-bit state, the main advantages are memory use and hardware implementation area. With 1024-bit state, a hardware implementation can be faster, but there are also security ...

1

No, it is not possible to get exactly equal probabilities for a deterministic mapping from all 256-bit numbers to the range 0-99. However, you can ask whether it matters, since a bias on the order of $2^{-256}$ is undetectable. A mapping that took the 256-bit number modulo 100 and refused the inputs less than $2^{256} \bmod 100$ would be unbiased and would ...

6

A fast 64-bit hash cannot be completely secure, since a $2^{32}$ brute force collision search is completely doable, and even a $2^{64}$ preimage attack could be feasible. As a MAC used for hash table keying, that doesn't really matter (unless you leak the key). Finding just a few collisions isn't a problem and gathering statistics for an attack would ...

3

This may just be a matter of terminology. A claim that an algorithm is "secure" is meaningless without qualifying/quantifying what it is secure against. Conventionally, the security/strength of cryptographic primitives is described and analysed in terms of computational and memory cost (i.e. secure against an attacker capable of performing a certain number ...

0

You could simply just XOR all the bytes of the hash to one single byte (lets call it $b$ for now): $b = hash_0 \oplus hash_1 \oplus ... \oplus hash_{31}$. $b \in [0, 255]$. Calculate $b' = b / 2.55$. $b' \in [0, 100]$.

8

If you mean exactly as likely, no, because the number of possible hashes is not a multiple of $100$. This is assuming all the hashes are exactly equally likely. You can come very close just by taking $SHA256 hash \pmod {100}$ This will be within one part in $\frac {2^{256}}{100}$, which is a very small number. If you want truly equal, check that the hash ...

5

First, I am assuming, per https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls, that the client handshake protocol in DTLS is not different from that in TLS over TCP. This seems a safe bet since the client/server encrypted handshake protocol in OpenVPN's UDP implementation is the same as in standard TLS over TCP. I am not ...

0

All the security definitions I am aware of for a cryptographic hash functions remain the same, if you apply a 1:1 mapping before hashing. In other words, if $f$ and $g$ are each others inverse, and $h$ is a secure cryptographic hash, then $x \to h(f(x))$ is also a secure cryptographic hash according to any security definition, I know of. Under such ...

5

Under the assumption that $(K,\text{Msg})\to H_K(\text{Msg})$ is a secure MAC (be it HMAC or any other MAC), and $\text{Nonce}$ does not repeat and is of fixed size, both $H_K(\text{Msg}||\text{Nonce})$ and $H_K(\text{Nonce}||\text{Msg})$ are demonstrably secure, in the sense that an adversary not knowing $K$ can't distinguish either from random, even for ...

4

One of the simplest associative functions that isn't commutative is concatenation: $$H(a,b) = h(a) || h(b)$$ Yes, it doubles the output length, but it is as strong as $h$ against collisions. I offer this partly as a serious suggestion (it's simple) and partly to illustrate that your requirements are quite broad.

5

If you don't need $H$ to be collision-resistant, you can use $$H(a,b) = h(a) \times h(b) \bmod p$$ where $p$ is a large prime such that $p-1$ has a large divisor (and in particular, the discrete log problem modulo $p$ is hard), and with $h:\{0,1\}^* \to \mathbb{Z}/p\mathbb{Z}$ a hash function that outputs numbers in the range $[0,p-1]$. If $h$ is a ...

4

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC? No, you don't need to do that, but you can. Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC? Yes, you can ...

Top 50 recent answers are included