New answers tagged

2

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


1

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


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


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.


-1

You really should never be truncating a hash. Really you're talking about the difference between traditional hashing algorithms and cryptographic hashing algorithms. A cryptographic hash algorithm has to not be predictable, while a traditional hash algorithm doesn't have that concern. You aren't guaranteed perfect random distribution, so really you ...


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


0

Collision resistance relates to how difficult it is to find a collision, not the total lack of collisions. In other words, a hash function $H(x)$ is collision resistant if and only if all attackers given reasonable computational resources (probabilistic polynomial algorithms) have only a negligible chance of finding two messages, $m_0$ and $m_1$ such that ...


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


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


0

By "one way function" do you mean preimage resistant, or do you mean that the function doesn't ever reveal the input? Assume H(x) is a collision-resistant function. Let L(x) = the last 256 bits of x. Then, let G(x) = H(x) || L(x) That is, G(x) is the concatenation of a collision-resistant hash of x, and the last 256 bits of x. Now, over all ...


0

A Cryptographic hash function as described in the literature has 3 criteria: Preimage resistance: Given $H,y$, it is "hard" to find an $x$ with $H(x)=y$ Second Preimage resistance: Given $H,x,$ it is hard to find $x'\neq x$ with $H(x')=H(x)$ Collision resistance. It is hard to find 2 $x,y$ with $H(x)=H(y)$ The very definition used (the first 1 and the ...


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


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


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


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


0

Conditions given are properties of all encryption algorithm if the encrypting key is constant. If mapping is bijective there will be no collision.


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


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


0

I do not agree to all of the combination advantages. All common memory-hard function are at the same time CPU-hard. And I'm not aware of an entropy reducing Password-based KDF in normal scenarios (of course any maximum password length theoretically reduces the entropy for larger pass phrases). There are also disadvantages: From the point of view of ...


0

You'd still need to iterate over all the possible passwords to do this, using a brute force or dictionary attack (i.e. a pre-image attack with regards to the hash). That is, unless the hash algorithm used isn't one way; i.e. you can retrieve more information about the passwords. A 32 bit hash is not common, so this could be possible. Fortunately most ...


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


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


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.


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


0

Have you ever considered to use for instance md5 and to modify the digest function in a way such that the round functions do not modify the said bits? its not really hard, you just need to add a few lines on each round function. I am not sure if this helps.


0

This looks like a (homework) assignment as the parameters are artificially small and the method is highly unconventional as opposed to the standard "You want the attacker to do more work?" - "Just increase the work parameter!". Because of this I'll give you some hints on how to solve this. Increase the size of the salt from 12 bits to 24 bits. You ...


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


1

Ok. I think I will attempt answering this myself. Given that (at least on linux), perl, openssl have gone down the same path as the rhash author (I am not sure who in fact, implemented this first), the reason for a different digest, is that, due to restricting the input message from $2^{512}$ bits to $2^{64}$ bits max, the first $512$ rows of $4 \times ...


0

Given the diagram, yes they are randomly selected keys, $P$ is a fixed plaintext and the projection of the output to the keyspace gives you the next input as key to the cipher, thus creating a pseudorandom walk through the keyspace.


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.


3

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


0

I would explore the GPU option before spending money on specialized hardware. I have done something similar using CUDA where I was doing many ECC operations in parallel. The GPU was about 30x - 50x faster than the CPU. You could probably hash the data on the CPU and then use the GPU for the RSA exponentiation.


1

As far as I know, some people use the term inversion per byte for the conversion functions of section B1 of the standard, i.e. h2b and b2h, which convert from the unusual (i.e. different than as in SHA1, SHA2 ) NIST bit encoding to Hex bytes. This is relevant only if you implement the API for hashing bit-string messages with non-zero bit length mod 8. ...


5

If $H(x) = x$, $x$ is a fixed point. If for a value the output of the function is the same as the input, it is called a fixed point. A length extension attack is unrelated to the concept of fixed points. There is a good question about understanding length extension attacks here.



Top 50 recent answers are included