# Tag Info

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

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

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

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

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

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

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

1

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

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

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

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})$$

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

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