New answers tagged

0

In short, no. Or rather, yes, but you don't want to do that. Note, by the way, that "can we do that" and "is it 100% secure" in your question are different, antipodal things. Much like "MT" and "secure" are antipodal. All generated pseudorandom numbers (including those coming from secure pseudorandom generators and those coming out of cryptographic hash ...


7

SHA-1 is broken in practice in terms of finding collisions. This shattered attack (identical-prefix collision attack) requires roughly $2^{63.1}$ SHA-1 evaluations and this is approximately 100,000 faster than finding collisions with generic birthday attack on 160-bit output that has $2^{80}$- time complexity. That is, for a hash function with $\ell$-bit ...


4

The approximate way You don't need to be perfectly even if you can make the unevenness small enough to be undetectable. So you can realistically do this: take the first 128 bits (16 bytes) from the SHA-256 output (or more, if you like), read them in as an unsigned bignum (arbitrary precision integer) using your library of choice, take the remainder modulo 6,...


0

First of all, even the entropy is 50-bit, it is not easy to list all possible string to execute an attack on the data set. Using hash can hide the data itself, however, the same data can have the same hash. Therefore, it can reveal information, especially there is also side frequency information about the data. This is a modern frequency attack and also ...


2

Can we use a Cryptographic hash function to generate ... Yes we can. Your code example shows that we can if the hash function is secure. That means a currently non invertible function. A slightly modified form is one of the older cryptographic Java RNGs, called SHA1PRNG. $$ \left\{ \begin{alignat}{7} & \texttt{State}_{0} && = \texttt{SHA}...


16

This construction gives you cryptographic-quality pseudorandom output, but it isn't as secure as it can be for a random generator. With commonly used hash functions $H$ (such as any of the SHA2 and SHA3 family), as far as we know, the bits of $H(\textrm{seed}, n)$ are unpredictable if you only know $n$ and $H(\textrm{seed}, m_i)$ for any number of values $...


4

Your scheme can be re-defined as; take a cryptographically secure hash function $\operatorname{H}$ and generate the sequence as; Init the seed with $\text{seed}= \text{"myseed"}$ $\text{hash} = \operatorname{H}(seed\mathbin\|counter)$ $\text{counter} = \text{counter} +1 $ output $hash_{|\text{required size}}$ (trimming the output) return step 2 for more ...


1

1) What common hash functions are worse than CRC checksums, and which are better than them in verifying integrity? (e.g. file corruption/changes). All cryptographic hash functions are better (ie. More secure) than CRC checksums. As the first answer from this question states: A checksum (such as CRC32) is to prevent accidental changes. If one byte changes,...


2

1) All common cryptographic hash functions are better than CRC, even MD5. This is due to the fact that they are designed to detect malicious tampering, whereas CRC is not. MD5 is still crackable, but CRC can be trivially manipulated. 2) hash function collision resistance determines how "good" they are at integrity verification, as there are more possible ...


1

The second paragraph of section 2 of the quoted paper tells the domain of the function $\mathcal F:\{0,1\}^{32}\times\{0,1\}^{256}\to\{0,1\}^{256}$. Under the reasonable assumption that for fixed second input ($h_{i-1}$ in the question's statement), $\mathcal F$ behaves as a random function of the first input ($M_i$ in the question's statement), then for ...


1

..how others have dealt with (bailing early if any of the deciphered bytes are wrong) A relatively common practice with this side effect is to restrict bytes in the plaintext to a certain discrete subset (e.g. Base64 characters, or those with an odd number of bits set) and stop at the first decoded byte that does not belong to this subset. Don't do this, ...


-1

Difference = none. A block chain is a linear series of data inter connected by cryptographic relationships. In your case it would be sha256. What constitutes data is entirely irrelevant and totally data agnostic. Do not confuse a generic block chain with Bitcoin. The data does not have to be transactional or singular. It could well be photos of my pet ...


1

The collision resistance of this hash will be the collision resistance of $\operatorname{HMAC-SHA256}_{IV}(M)$. Beware of the fact that pre-hashing of the key is a thing with HMAC, so $$\operatorname{HMAC-SHA256}_{\text{ReallyLongIV}}(M)=\operatorname{HMAC-SHA256}_{\operatorname{SHA256}(\text{ReallyLongIV})}(M)$$ Do I still need to include file length in ...


2

This is called a stream cipher. It is a practical instantiation of the one-time pad model, where we encrypt a message $m$ with a single-use pad $p$ by using the ciphertext $c = m \oplus p$. When $p$ is generated from a short key $k$ by $p = F(k)$, obviously $c$ and $m$ are not technically independent—we can't say of the probabilities that $P(m \mid c) = P(...


0

You can use Hash(element:nonce) then increment nonce until the result is prime. Check section 7 "Hashing To Primes" of paper "Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains" Hash() can be SHA256 for example.


2

Suppose the input of SHA-512 is 512 bits of data (so exactly the same size as the output). If I would test every possible combination (so $2^{512}$ calculations), then will the output also be exactly $2^{512}$ different hashes, or will collisions occur? It would be astonishing if SHA-512 turned out to be a permutation on 512-bit inputs, so no, absent a ...


4

If you skip the padding and final non-padding characters then yes, each character should be equally likely. The output of SHA-256 is indistinguishable from random if you cannot guess the input. This also goes for iterations of the hash calculations over itself. The final characters are not over just SHA-256 but are padded with zero characters. This is ...


8

In short: Will every possible 'final' password be equally likely? Yes, we expect that they equally likely. Cryptographic hash functions expected to have a well-distributed output. If you find any bias, you can convert this into an attack. Even there is a tiny bias then that can be used to attack for the hash function. You seem like you are going to use the ...


4

The problem with passwords or, more succinctly pass phrases, is that they are often relatively easy to guess. Password strength - or rather the lack of it - is a common problem. The strength of a password is not such a big deal if there is some kind of control over how the password can be used (e.g. a PIN is relatively easy, but you are only allowed 3 tries)....


1

The number of NVIDIA TESLA V100 in the Summit supercomputer is documented, and it's reasonable to assume that most of its hashcat performance for SHA-1 would come from that: according to this source on the Power9 CPU ISA, there is no SHA-1 instructions for the Power CPUs, and then these benchmarks give an order of magnitude on other CPUs. Isn't that enough ...


7

No, the length extension attack/property is not considered a collision. It does not allow to build a collision. The length extension property is that given the hash of a bitstring $M$ of given length $l$ (but arbitrary and unknown content), it is possible to compute the hash of $M\mathbin\|F(l)\mathbin\|E$ with $F(l)$ a short bitstring deduced from the ...


0

Any experiment made with SHA-256 or any truncation of that, devised without knowledge of SHA-256 (or just without knowledge of its constants h0..h7), and with input length constrained to block the length extension property (e.g. fixed), should conclude that the output behaves like uniform random, except that identical input leads to identical output. Any ...


7

If this provided any insight, we would consider SHA-256 to be broken. In general, we expect the $n$-bit truncation of SHA-256 to resemble an $n$-bit uniform random function. For example, finding a 10-bit partial preimage costs an expected ${\approx}2^{10}$ trials; finding a 10-bit partial collision costs an expected ${\approx}2^5$ trials. That said, there ...


3

Why not use chacha derivatives (BLAKE, rumba) to make an [H]MAC for use with chacha? Why use poly1305? Performance. Poly1305 is extremely cheap to compute, and the computation can be essentially arbitrarily parallelized, because it's just evaluating a polynomial modulo $2^{130} - 5$. In contrast, functions like BLAKE2 and Rumba20 can't be parallelized ...


5

Why is stock chacha20 not good as a cryptographic hash? You haven't specified what kind of ‘cryptographic hash’ you mean, but since you're comparing it to BLAKE, it sounds like you're looking for collision resistance, which was the central motivation for the whole SHA-3 competition in the first place after MD5 and SHA-1 fell to collision attacks in 2004/...


5

OK, so the core ChaCha primitive (for any fixed number of rounds) is a function $\operatorname{ChaCha}: \{0,1\}^{256}\times \{0,1\}^{64}\times\{0,1\}^{64}\to \{0,1\}^{512}$ which is believed to be a secure PRF when the first input is the key. So now that we know what ChaCha is, for the three desired functionalities: MAC. Of course a PRF is also immediately ...


10

I'm answering the following which was asked in the original question: Why is stock chacha20 not good as a cryptographic hash? Why create BLAKE? Why not simply apply the one-way compression function concept on raw chacha20, specifically its quarterround() function, unaltered. TL;DR: Chacha was meant as a stream cipher, it needs a different kind of ...


7

OK, so the core ChaCha primitive (for any fixed number of rounds) is a function $\operatorname{ChaCha}: \{0,1\}^{256}\times \{0,1\}^{64}\times\{0,1\}^{64}\to \{0,1\}^{512}$ which is believed to be a secure PRF when the first input is the key. So now that we know what ChaCha is, for the desired functionality of hashing: At a fundamental level it's unclear ...


1

Assuming our domain and codomain both have 4 elements, the uniform distribution of inputs to outputs means the function is injective. You seem to be using the standard technical term ‘uniform distribution’ in a confusing way. Normally the uniform distribution on a finite set $A$ means the probability distribution $P$ with $P(x) = 1/\#A$ for all $x \in A$, ...


-1

Assuming our domain and codomain both have 4 elements, the uniform distribution of inputs to outputs means the function is injective. No. This is not a cryptographic hash (what I call a pseudo random function). Simplistically: Hash -> avalanche effect -> bin collisions -> 37% rate -> non injective -> codomain =/= domain. You may be over thinking this. ...


1

Well, not exactly. The hash function that your MD internally uses a compression function $f:\{0,1\}^{256} \to \{0,1\}^{128}$ MD construction uses an IV, in your case 128-bit feed into the first call $f$. The first input and output of $f$ is $h_1 = f(IV\mathbin\|m_1)$. From these, you can deduce that you must divide your message $m$ into 128-bit blocks. ...


Top 50 recent answers are included