Tag Info

Hot answers tagged

8

Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication? Yes. That is a semi-serious answer; both are very good choices, assuming, of course, that a Message Authentication Code is the appropriate solution (that is, both sides share a secret key), and you don't need extreme speed. How much HMAC-SHA256 is slower than HMAC-SHA1? Those ...


8

If you mean exactly as likely, no, because the number of possible hashes is not a multiple of $100$. This is assuming all the hashes are exactly equally likely. You can come very close just by taking $SHA256 hash \pmod {100}$ This will be within one part in $\frac {2^{256}}{100}$, which is a very small number. If you want truly equal, check that the hash ...


7

It is possible to turn a hash function into a stream cipher; there are several methods for that, and the simplest is to compute $h(K||IV||x)$ for hash function $h$, initialization vector $IV$, and successive values of a counter $x$. This yields an arbitrarily long sequence of pseudo-random blocks (32 bytes per invocation if $h$ is SHA-256). Then XOR that ...


7

Uniformity is a tricky one. SHA-256 (as well as SHA-3 for that matter) follows a heuristic approach. That is, the design is not based on a hardness assumption (for example, the factoring or discrete-log assumption) but on criteria that have only been verified empirically. As such, also the study of uniformity is an empirical study. The development of ...


6

Is it possible that hashing "foobar" recursively an infinite amount of times will eventually yield any arbitrary hash value? I very much doubt it. A simple demonstration of this logic can be done through the birthday paradox. Suppose we log each successive recursive SHA-256 on "foobar" in a table. We can ask ourselves what the probability is that our ...


6

The Bitcoin mining algorithm can not be simplified by exploiting any weakness in the SHA-2 hashing algorithm with the current state of the art. The problem is manyfold. From the SHA-256 point of view, there is no (partial) preimage search algorithm that applies to the full hash function. Even worse, the attacks that penetrate a fewer number of rounds have ...


6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...


5

Yes, you should be able to handle this situation readily. There are many optimizations available. One key observation is that if you're going to go to disk, then you might as well read lots of data: it takes just as long to read an entire block of data as to read 1 byte. So, I suggest you store the data on disk in 4096-byte blocks, and do a Merkle tree ...


5

Unfortunately, without some additional assumptions about the strings (e.g. that the first 8 bytes are unique), there is no way to reduce the chance of collision below the usual chance levels. If you need unique 64-bit ids, the options are: Do a database lookup when generating keys and pick another key if it is already in use (you state that you want to ...


5

Yes, your MAC is secure. It's probably not quite as secure as you're expecting it to be, and it's not a construction I would recommend to anyone, but it should be secure. Let's start with a simpler variant: $F_K(M) = E_K(H(M))$ where $H(\cdot)$ is a 128-bit collision-resistant hash (say, the first 128 bits of SHA1) and where $E_K(\cdot)$ is a 128-bit ...


5

I agree with the comments that SHA-256 should be fine here. However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply: $$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$ where 'info' is an ...


4

If I were to guess on what might be wrong on code I haven't seen, well, with SHA256, you stir in a per-round constant. Maybe the constant you have for round 24 (which should be 0x983e5152 if you count rounds from 0) is wrong...


4

It's probably a really bad idea to try and roll-your-own here. If you have to ask a question like this, you would probably just be better off using shrink-wrapped solution like SSL rather than trying to make your own protocol. There are a lot of tricky problems around getting these kinds of things right. However, if you insist on doing this yourself, there ...


4

This would hopefully eliminate the worry that somebody could reverse-engineer the process by which I generate the brain wallets. By Kerckhoffs's principle, you should assume that the adversary already knows the algorithm, and the only thing unknown are the secret keys – in your case, the passphrases. Therefore, the adversary by definition knows that ...


4

From RFC 5246, section 6.2.3.3: AEAD Ciphers: AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used. However in RFC 5246, section 5: HMAC ...


3

No, there is no security decrease in this case. While there could be some hypothetical constructions that might leak the preimage if two images are known, this is definitely not the case for existing hash functions, which are all quite different from each other. An example of such a weak pair of hash functions could be two versions of MD5: one with 63 ...


3

The security concern is that the result of that operation will be guessable without the secret number, since the later part of that answer explains why it also applies to SHA-256. (Also, $\:$ SHA256(A+"") = SHA256(A)$\:$.) The random number should be long enough to make brute-force highly infeasible. If it is and you publish HMAC(A,"") and present them ...


3

What you (most probably) describe is called a "preimage attack", where the attacker tries to find a message that has a specific hash value. Some related attacks against reduced/weakened versions of SHA-256 are known, but (as far as I know) no such attack was successful against the standard SHA-256 algorithm up to today. So generally, it can be to be ...


2

As both of us recently learned, the public key signature hash algorithm is negotiated completely separately from the MAC algorithm. DSA and RSA use SHA-1, ECDSA uses SHA-2, and Ed25519 uses, um, Ed25519. I'm skeptical that SSH crypto performance will be a serious issue for you. I suspect you would have to be transferring a lot of data on a really bad CPU ...


2

Actually, this sort of programming question is more suited for stackexchange. However, to answer your question, there are two obvious approaches to speed up a collision search: Use a Hash table; that is, instead of keeping everything on one big list, divide them onto (say) 1024 different lists (in such a way that you know that items on two different lists ...


2

It may be that you did not actually observe an unexpected deviation from the desired mean of 50.5 for a uniform distribution over integers in [1,100]. However, you say that all combinations of two characters are considered, which I assume to mean that first you look at characters 0 and 1, then characters 1 and 2, and so on. This means that when you look at ...


2

The variables a, b, c, d, e, f, g, h are assigned on each round of the compression function main loop, but the interim hash values are considered only per message chunk (i.e. after all rounds have completed) I found the Wikipedia pseudo-code easier to understand than the description in your question, and it is clear there how the variables relate to interim ...


2

Theoretically, a hash function can be insecure and leak information about the plaintext. In this case knowing multiple hashes will let you make use of weaknesses in any of them. I agree with Dmitry Khovratovich that this isn't likely if you choose hash functions that are considered good, but it is a possibility. More concretely, knowing multiple hash ...


1

However, if instead you truncated the hash to (64 bits - X bits), and concatenated the resulting hash with the first X bits of the input string, you'd reduce the chance of collision since two similar strings are unlikely to produce the same hash code: For a good cryptographic hash a given similar string is just as likely to have a hash collision as a ...


1

Ferguson and Schneier define SHAd-256 in their book Practical Cryptography in Chapter 6.3.1 Length Extensions. For any hash function SHA-X, where X is 1, 256, 384 or 512 we define SHAd-X as the function that maps m to SHA-X(SHA-X(m)). In particular, SHAd-256 is just the function m ↦ SHA-256(SHA-256(m)). They clearly defined SHAd-256 to prevent length ...


1

The current status as of the time I write this is: There are no known attacks on second pre-images for truncated SHA-256 that are faster than brute force.


1

It seems that djigzo uses bouncycastle and if you look in the source at the DefaultSignatureAlgorithmIdentifierFinder, e.g., here, then you find: algorithms.put("SHA256WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha256WithRSAEncryption); algorithms.put("SHA256WITHRSA", PKCSObjectIdentifiers.sha256WithRSAEncryption); Thus, it seems that both refer to ...


1

Is this a sound way of doing things? Depends. Where do the keys come from? If they come from a user's memory (e.g., a password) then no. The reason for this is that a simple hash if fairly fast to compute. Typically we recommend people use something like PBKDF2 or scrypt as they run through thousands of iterations. The effect of this is that computing ...


1

The counter is used to distinguish the different (session) keys used in the protocols. A relatively standard KDF is used, KDF2. Note that only a single iteration is needed and that no OtherInfo has been defined, so the specification of KDF2 may look more complex than it is in the PACE protocol. A 32 bit counter is of course overkill for the protocol, but ...


1

Generally seeds for PRNG's should be mixed in with the internal state using a hash function, and the output should be at least a hash away from the internal state. You could take some hints from the implementation of SHA1PRNG in the Sun JCE or from other hash based PRNG's on how to do this. You do not want to forget the internal state, because in that case ...



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