# Tag Info

3

Ok, here's how it is supposed to work: we take the function (which maps a string of $n$ bits to a string of $n$ bits), and iterate it repeatedly. After some amount of time, we'll run into a loop (that is, we'll evaluate to a value that we visited before, and there after, we'll repeatedly run through the loop). And, we'll run the function iteration twice, ...

0

Since it's your homework, I'll only hive you the direction and not a full formal proof: a) if at least one of H1 and H2 are collision resistant then H is too. Because if H is not coll-resistant then it's possible to find x and x' s.t. H(x)=H(x') so H(x)=H1(x)||H2(x)=H1(x')||H2(x')=H(x') which means that H1(x)=H1(x') and H2(x)=H2(x') so we found a collision ...

0

You may find this example instructive... keeping in mind it's a pre-print first draft. http://unitambo.files.wordpress.com/2014/05/one-way-function1.pdf http://unitambo.wordpress.com/spreadsheet-model/ An iterative hash function as an information preserving, binary modulated mapping of x-->x, has a ternary inheritance identity by way of its inverse ...

0

Yes, a hash function can become an encryption function this way. I posted something similar a while back: Hash Based Encryption. One thing that is sub-optimal in your approach, is that it isn't a stream cipher. If you encrypt 500 GB of data using this method, and then at some point in the future you only need to decrypt the last 3 KB of the data, you still ...

1

Another way to encrypt with a hash function is chaffing and winnowing.

2

Yes, it is possible to turn a hash into a secure cipher, though not in the manner described. The encryption scheme described is extremely poor: if someone can guess the first 32 bytes of the message (e.g. because that's a standard file header), it is trivial to recover SHA256(key): that's the XOR of the 32-byte guess and the first 32 bytes of ciphertext. It ...

7

You can in principle encrypt using a hash function, in the manner you describe (although what you have described is not necessarily a secure construction). What you are trying to do is generate a keystream from a hash function and a key. You can use counter mode to turn any strong pseudorandom function (PRF) into a stream cipher. CTR mode produces a ...

1

According to this primitives like AES and SHA generate proper pseudo random numbers that pass relevant tests. Hence, your scheme should be sufficient for generating a stream of random bytes as encryption key for stream cipher. Although, it should be noted again (as you already did): You do not generate a real one-time pad, but just a stream that might look ...

2

One of the main reasons for hashing is that hashing destroys any algebraic structure that is hidden in the signatures. If you don't hash, then in most signature schemes the messages will satisfy some algebraic relation. A typical example is that $$Sign(m_1m_2)=P(Sign(m_1),Sign(m_2))$$ meaning that the signature of a product/concatenation/whatever of two ...

0

Alongside the other arguments: signing (with RSA) means exponentiating it modulo $N$ (with power $d$, the secret exponent). So anything you sign that way must be of bitsize smaller than $N$, and hashing (plus padding it) makes it so. Otherwise you'd have to split the message in small chunks and sign them, and concatenate the chunks etc. This would make the ...

0

To add another point to what Travis has already mentioned, some signature schemes like textbook RSA signature is not EUF-CMA secure under random oracle model, but Hashed-RSA signature is. So, even for a small message is would would be better to hash-then-sign, though it is not an efficiency concern.

1

Because signing is very expensive and hashing is orders of magnitude faster. If your message was a gigabyte, for instance, it would take many minutes to sign it. With hash-then-sign it is only a few seconds. Also without the hash the signature of a message would be as long as the message itself, which can be inconvenient.

1

The function $e$ takes two values: $x$ and $H$, and then merges them in a specific way. Your "way" is just XORing them. That's insecure, as you can see. Normally you use a block cipher for the function, like AES-128 for an input of 128 bit. Example: $$H_i = H_{i-1} \oplus AES_{xi}(H_{i-1})$$

0

Davies-Meyer is a compression function construction. You need to call a block cipher with your to-be-hashed data as the key and the chaining value as the plaintext. You then XOR the plaintext to the output of the block cipher call to obtain the next chaining value.

1

Since you already know $K$, you just need to know the length of $H$ based on the hash algorithm you are using, which should be constant, then simply split the output of $D_k$ into the 2 parts of appropriate length. You can then perform the keyed hash on the first part and match it against the last part, which will match if the decryption was successful. It ...

0

When the output of the hash function is $n$ bits, then there are $2^n$ possible outputs. For a preimage attack you are given a hash $h$ and you need to find a message $m$ where $h = H(m)$. Since there are $2^n$ possible outputs, the probability of guessing an input that that maps to the given output is $\dfrac{1}{2^n}$. So on average you need to try $2^n$ ...

0

Few answers to your questions Storing per address salt (assuming you are using it for encryption) is not same as storing the mapping with the hash. Salt could be public. You could encrypt anything with a public key for which there is no private key yet, Checkout more on Identity based encryption techniques. Few additional inputs for anonymization Any ...

0

The question states that the probability of finding a collision is $2^{-64}$. This is incorrect. The probability depends on the number of available messages, as we will see below. If you take two random messages, the probability of them having the same $m$-bit hash is $2^{-m}$. So you're going to have to try around $2^{m}$ pairs before you find a collision. ...

4

A long message is a message that, when padded, is longer than the block size of the hash function. That means that the hash function has to process the message in parts and keep track of state somehow, which may allow for attacks. Such attacks would not apply to messages shorter than the block size, and may additionally require a large number of blocks to ...

1

A CRC or some other similar scheme is superior as they can be engineered such that single character changes or transpositions can be detected. A Bitcoin address uses a truncated hash function as a "checksum" but it is easily possible to have two valid addresses differing by one character 1ByteCoinAddressesMatch1kpCWNXmHKW 1ByteCoinAddressesMatch1kpCxNXmHKW ...

4

Without the specific reference I can't be sure this is what you are talking about, but generally a "long message" attack is a way to defeat second preimage resistance with less complexity than expected. It uses a time-space tradeoff to find a second preimage with complexity $2^{n/2}$ for a $n$-bit hash function (normally you would expect $2^n$). In the ...

4

If we're talking about a malicious and intelligent attacker, you are mostly wrong, but not for the reasons you might expect. If we assume an intelligent attacker, then a CRC does not help; they can obviously modify a file, and either figure out how to update the CRC32, or how to make sure that the modifications do not change the CRC. On the other hand, if ...

2

Check out Manuel Blum's human computable hash function. He calls it HCMU for Human Computable Machine Unbreakable. He claims you have to spend an hour memorizing the technique and then you can apply the has function in about 20 seconds without even using pencil and paper. The memorization required is to remember a random mapping of each letter of the ...

2

I need a small clarification that why openssl using SHA1 in ECC when I am using secp384r1 curve, but in rfc they are saying we should use SHA2. OpenSSL uses SHA-1 because RFC 4492 defines the use of ECC on SSL with SHA-1. It should also support SHA-384 as defined in RFC 5289. Which hash algorithm is used in TLS depends on the cipher suite. For example: ...

0

You can make incremental changes that only touch small pieces of the file faster, at a cost in complexity. Multiple hashes can help with that. Rather than a single hash value, you can amortise the cost of computation by storing multiple hashes. If you hash the large file in pieces, then you can create a single hash that covers the entire file by hashing ...

0

Your idea does not seem to provide any security benefit. If an attacker was able to modify the data while preserving the MD5 hash, your encrypted MD5 hash would also stay the same. One practicable aproach would be to simply use MD5 hashing. To tamper with the data without changing the hash, an attacker has to perform what’s called a second-preimage attack ...

Top 50 recent answers are included