# Tag Info

7

Hexadecimal is traditional -- by this, I mean that there first were command-line tools that used hexadecimal for output, then other people using the hash functions found it fit to stick to hexadecimal, if only to be able to compare their values with the output of the aforementioned tools. That's how traditions get established: a more-or-less random choice at ...

7

It is going to be pretty hard to achieve collision resistance without one-wayness. Indeed, negation of one-wayness means that for a given output, you can find a corresponding input. So a collision is easily obtained by simply choosing a random input m, hashing it into output x, then finding a preimage m' for the obtained output x. The only way for such a ...

4

Per my comment, I'd like to suggest a definition for "non-iterative hash function", and propose some constructions that fit the definition. I will also suggest an alternate name (though it may not help much with searching for papers on the topic). Let $\mathcal{M}$ be the message space of a hash function, e.g. $\mathcal{M}=\{0,1\}^{*<\ell}$, the set of ...

4

When designing security for a physical safe, one of the critical specifications is how long will the safe resist attack, this tells you how quickly you must detect and respond to an attack on the safe. Yes, however there's a key difference between physical safes and cryptography. With a physical safe, the attackers must be present on site (if they ...

4

Should be comparable in strength to $H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is $\min(2^{n_O},2^{{n_I}/2})$ where $n_O$ is the output size of the outer hash and $n_I$ the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ...

3

The strength here depends on the collision resistance of $H$. If $H$ is not collision resistant, like MD5, then the attacker can find $H(m) = H(m')$, ask for the MAC of one message and forge it for the other. So for many secure hashes you lose half the security bits. E.g. SHA-256 should give you a 256-bit secure HMAC, but would be at most 128-bit secure in ...

3

If $f:\{0,1\}^m\rightarrow \{0,1\}^n$ with $n\geq m,$ then of course there are, the set of one-to-one functions, but such a function is not a cryptographic hash function, since it lacks the compression property. If $n<m,$ (or more generally if $|X|>|Y|$ for $f:X\rightarrow Y$), collisions will happen.

3

Suppose we try C(password) = A(password) + B(password) where + is just concatenation of the hashes. The result of this is obviously a weaker hash: we can preimage C by finding the original password by cracking A or B. This is incorrect with the standard notion of preimage resistance. Because there are many more possible inputs to a hash function ...

3

First of all, the usual way to do this is to generate a new random AES key and then wrap it with the public key. Generally you don't encrypt with the private key at all. Yes, SHA-256 is a one way hash so you can do this. The problem is that you would still need to encrypt with a public key to let the other party know the AES key (unless you use the key to ...

3

So let's start with the hash functions: $$H_n:A\times B\times C \rightarrow D$$ is the mathematican's notion for a function called $H_n$ that takes arguments from the sets $A,B,C$ (in this order) and maps it to $D$, where $B,C$ are optional. You're facing three types of sets for this: $\{0,1\}^*$ is the set of binary bit-strings of arbitrary size, e.g. ...

3

There is no difference. The wiki page you referred to contains examples of hashes for all three versions of Whirlpool. For string "The quick brown fox jumps over the lazy dog", the current version should produce the following hash: B97DE512E91E3828B40D2B0FDCE9CEB3C4A71F9BEA8D88E75C4FA854DF36725F ...

3

You cannot uniquely invert it. Your hash will have the form $$y_1 \quad y_2 \quad \dots \quad y_m$$ with $y_i=\sum_{k=1}^m x_k^{i-1}.$ First look at the special case $m=2$. $y_1$ will always be $y_1=m=2,\,$ the other equation is $y_2=x_1 + x_2$. You cannot uniquely determine both $x_1,x_2$. In the general case you have $y_1=m$ and $m-1$ equations for the ...

3

I think you could calculate it manually or write code to solve this. You need to calculate X values from starting with end. For example : $X_{32}$ = 84 = $X_{32}^{31}$ $mod_{117}$ When you get $X_{32}$ value then you can calculate $X_{31}$: $X_{31}$ = 62 = $X_{31}^{30}$+$X_{32}^{30}$ $mod_{117}$ The only unknown value is $X_{31}$ here. You need ...

2

But is it necessary to use these bytes? Yes, it is, at least for most messages that you'll see in practice. MD5 works by taking the message, and applying a fixed padding to it. This fixed padding involves, for messages which are a number of bytes (as opposed to, say, a message of 119 bits) an 0x80 byte, and for not huge messages, 0x00 bytes (in the ...

2

You can't compute these without a lot of other parameters, the most basic being the size of the keyspace you are searching, are you using perfect vs non-perfect rainbow tables, etc. See, e.g., this paper on eprint for the gory details.

2

It would be good to define what you require for the cipher to be secure before trying to determine it's security properties. Take the example of CPA security - Katz and Lindell (Introduction to Modern Cryptography 2nd ed.) state that a symmetric scheme has indistinguishable multiple encryptions under chosen plaintext attack (i.e. the scheme is CPA secure for ...

2

Bruce Schneier writes in Applied Cryptography (2nd ed., p. 38f): In practical implementations, public-key algorithms are often too inefficient to sign long documents. To save time, digital signature protocols are often implemented with one-way hash functions (...). Instead of signing a document, Alice signs the hash of the document. The references ...

2

Thomas Pornin already explained why such a thing is not usually possible, but I would like to quote a graphic from Rogaway and Shrimpton's "Cryptographic Hash-Function Basics: Definitions, Implications, and Separations for Preimage Resistance, Second-Preimage Resistance, and Collision Resistance" (pdf): The dotted arrow from Collision resistance to ...

2

Actually, the strength of the derived key is likely to be limited by the strength of the password; for example, if the user selects the password "password", well, that's likely be to within the first couple that an attacker checks. However, if we assume that the password is stronger than what most people select, then the next limiting factor is $n$. The ...

2

Use the number of occurrences of each letter as the unknowns you're solving for. This gives you 32 linear equations to solve for 16 unknowns. Use standard approaches for solving systems of linear equations. Finally use the fact that the letters are ordered alphabetically to reconstruct the $x_i$ values.

2

Is there any possibility to make a successful verification with just modifying message and signature, and without modifying public-key ? One would certainly hope not. If you can, then you've just shown that the signature algorithm used is broken, and not to be trusted. For a signature method to be considered secure, then it is required that someone ...

2

It is not collision-resistant because the tag is only 64 bits, so on average only $2^{32}$ inputs are needed to find a collision. This is the classic birthday bound. This is completely insecure, so SipHash is not collision resistant. This is not a problem for hash tables because hash tables have collision-resolution mechanisms and because the odds of a ...

2

You are correct: The 'workhorses' or primitives of cryptography, hash functions and block ciphers, can be used in such a way that they accomplish each others tasks: A hash function can be used to generate a key stream just as a stream cipher or block cipher in CTR mode (see e.g. Salsa20). And a block cipher can be transformed into a hash function (e.g. a ...

1

In general, you never want to use CRC/weak checksum for any computations on secret material (like keys). CRC is a linear function and by showing CRC of a key, you reveal a lot of equations that hold among the key bits. This is equivalent to showing the same number of bits of the key as the length of the checksum. The proper way of doing it has been ...

1

I'm not a Java programmer, and I didn't compile this, but I modified answer to this question to achieve a hash chain of length equal to four. byte[] bytesOfMessage = yourString.getBytes("UTF-8"); MessageDigest md = MessageDigest.getInstance("MD5"); byte[] thedigest = md.digest(md.digest(md.digest(md.digest(bytesOfMessage)))); PS. Don't use MD5 for ...

1

This is secure assuming that the hash function is a PRF. It is also secure for common Merkle-Dämguard hash functions like SHA-256. Furthermore, it is secure if one uses a $n × n \rightarrow n$ compression function $F$ as $C = P \mathop{xor} F(\mathop{Key}, \mathop{Nonce}||\mathop{Counter})$, provided that $F$ is a PRF and $n$ is large enough to prevent ...

1

On the practical side of things, if your hypothetical function is hard to invert, and assuming collisions are hard to find, why does it matter that it be bijective? For sufficiently large $n$ you can't construct a counterexample anyway, so a hash function may as well be bijective as far as anyone cares. Otherwise, not exactly what you're asking for but you ...

1

Correct me if I am wrong $xH_1$ $(ID_A,w_0)$ means $x \times H_1(ID_A) \oplus H_1(w_0)$ where $x \in Z_q^*$ It is hard to formally respond because I don't have access to the paper you mention but with common sense, just by reading the $H_1$ definition, $xH_1$ $(ID_A,w_0)$ means $x \times H_1(ID_A, w_0)$ where $ID_A \in \{0,1\}^*$ and $w_0 \in Z_p^*$. ...

1

Let's consider a platform with 63-bit unsigned integers, and no support for 32-bit or 64-bit unsigned integers. We can implement SHA-256, or SHA-1, or MD5, with fair efficiency. The idea is to use 63-bit int for 32-bit unsigned variables, and perform masking to 32-bit only where needed. A simple implementation of SHA-256 could have the critical loop coded ...

1

It would be possible to modify some scheme to move use 63-bit words, but that would require cryptanalysis and new choices for constants. I am not aware of any hash families that would be parametric with regard to word size and allow such uneven values. Instead I would recommend using any existing hash that internally uses 32-bit words and that does not use ...

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