# Tag Info

7

Hash + digital signature If the hash is not collision resistant, the attacker can produce two messages having the same hash. They'll request a signature on the first and present the signature on the second, a forgery. When second pre-image resistance is violated, this attack becomes much more severe, since now the attacker doesn't need control over both ...

6

Your intuition is on the right track: if you run a pseudorandom function in counter mode with your secret key, you get a stream cipher. Some stream ciphers are designed like this, perhaps most notably Salsa20 (and its later variant ChaCha20). But the key to answering your question, as I see it, is to note that a collision-resistant hash function like SHA-2 ...

5

It is widely known, generally, that a MAC is a HASH with key. Nope; there are plenty of perfectly good MACs that, if you know the key, aren't very good hashes at all. Examples of this would include CMAC and GMAC; in both cases, if you know the key, it's easy to generate an image that MACs to a specific value. However, lets assume that you're talking ...

4

The first hash is only used to hash the label. Most of the time the label will simply be empty, which means that a constant value can be used, identified just by the hash algorithm itself. Although the hash values may differ and may have any SHA-x value, they are generally set to SHA-1 - which is the default. Note that SHA-1 is considered secure for MGF-1. ...

4

Does many:1 mean two different inputs would have the same hash outputs? Yes. This is a consequence of the pidgeonhole principle: as MD5 has a much larger number of potential inputs ($2^{2^{64}}$ or so) than outputs ($2^{128}$), some inputs must lead to the same output, i.e. collide. Cryptographic hashes all have this "limitation", because they have a ...

3

Yes, these are public parameters of the system. Note that NTRU is not implemented exactly this way any more. The most up-to-date current spec is EESS#1, which can be obtained from https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/doc/EESS1-v3.1.pdf.

3

The key thing you're missing here is that collision resistant hash functions ("CRHFs," what we normally call just "crypto hashes") and message authentication codes ("MACs") have substantially different security goals. CRHFs must meet these goals: Collision resistance: Attacker can't easily find two messages that hash to the same value. Preimage resistance:...

3

Which MAC algorithm is faster - CBC based MAC's or HMAC - depends completely on which ciphers and hashes are used. Furthermore, it depends on the runtime environment that contains the hash and cipher implementations. With regard to the leading CPU architecture for PC's, there are the Intel whitepapers. Both AES and SHA-2 performance can be enhanced using ...

3

Are there any security issues related to use the same SALT in PBKDF2 for all IDs? Yes, you can build a rainbow table or brute force the ID's. An attacker could build up a table with tokens. Once the table exists the attacker can try all possible ID's until one of them matches. That way the function is reversible and your requirement to keep the ID secure ...

3

If I understand you correctly, you are using the Simon key expansion process, so that the input to your block is the 256 bit Simon key, and the output is the 256 bit last round key (and you're ignoring the Simon encryption process entirely). If so, three nits: I believe that you can find preimages for your hash function in $O(2^{64})$ compression function ...

3

The standard definition of a hash function is from arbitrary length bitstrings to a constant length bitstring. That is, there is only one input. Password hashes, like keyed hashes (MACs, more or less), have more than one input. There is no contradiction there, since password hashes are not cryptographic hashes - thought they may be built from cryptographic ...

3

I should have started here: sub scrypt_hash { my ($key,$salt, $N,$r, $p) = _scrypt_extra(@_); return undef unless defined$key && defined $salt && defined$N && defined $r && defined$p; return "SCRYPT:$N:$r:$p:" . MIME::Base64::encode($salt, "") . ":" . MIME::Base64::encode($key, ""); } It explains that the last ... 3 By trying all the 128 different bit position on the state, 19 rounds (over the 64) are required for a full avalanche effect (source code). round 0: 00000000000000000000000000000001 00000000000000000000000010000000 00000000000000000000000000000000 00000000000000000000000000000000 round 1: 00000000000000000000000000000000 00000000000000010000001000000000 ... 2 ⊕ is a relatively simple operation, so$h(x)$can be calculated quickly. preimage resistant: No. Given$h(x)$, we can construct$M_1||M_2||...||M_l$in an arbitrary manner. Since we know h(m), we have a 160 bit string of 0s and 1s. For each 0 in$h(M)$, we can assign an even number of 1s (or all 0s) to that position in the l blocks. For each 1 in$h(m)$, we ... 2 The inverse cannot be calculated, you're right. However, in can be guessed. In many scenarios, for example cracking hashed password, it's enough for the attacker to know a set of possible inputs which result in certain output (of course if their number is reliable) instead of one certain value. So if the one-to-many function is weak, given the output$y$... 2 The hashing function you describe would be a magical compression method. Well, I'm sorry to burst this on you, but magic isn't real. Magical compression that can take arbitrary data and condense it to a very small size does not exist. In fact, it's easy to prove mathematically that there is no compression method that reduces the size of all data, by the ... 2 Is it necessary to have 50 000 different reducing functions to avoid the collisions? Yes. If you do not have different functions it is not a rainbow table. It is just a table of hash chains which is less efficient, especially for high coverage tables. However, the functions do not have to be unrelated, just different. How do I create those ... 1 A compression function is necessary to fulfill the requirements of a hash function. This is because hash functions are expected to be able to accept as input bit strings of arbitrary length, and output a bit string of a constant length*. The specifics of how the compression function compresses the input string is particular to the construction of the hash ... 1 If you are imagining something like 256+ bits of key -> SHA-256 -> one block keystream that you XOR with the plaintext, that is indeed almost the same as one-time pad. However, there is no advantage to doing that, considering you might as well have used the original key directly as a one-time pad. If, instead you use a password-based hash, a dictionary ... 1 Is it sufficient to show that we cannot calculate the inverse of the function because it is a many to one function and not a one-one function. It would depend on what you need your function for, but by the standard definition of pre-image resistant, no, it's not sufficient. In the standard definition, it must be infeasible, given$x$, to find any$y$such ... 1 Number of inputs Hashing algorithms usually take more than one input. For instance, SCrypt takes 5, but only one field represents data to be hashed. The rest are salt and hardness configuration values. It doesn't really makes sense to have more than one data field to be hashed, because most modern hashing algorithms require a unique value (salt) to be ... 1 In principle, a signature can always be used in lieu of a MAC. You use a MAC when you want the legitimate recipient of a message to be able to verify its authenticity. With a signature, everyone, including of course the legitimate recipient, can verify the authenticity of a message. The reason we use MACs at all, instead of just using signatures all the ... 1 Question1: How can we show/prove that the random element only with a negligible probability can have such structure? If we assume the random oracle model and have$h: \{0,1\}^* \to \{0,1\}^n$then we can state that$h(.)$is equivalent to randomly sampling from$\{0,1\}^n$. Thus for a random element$r = r'||r''$the probability that$r$has the structure$...

1

The answer "GCM is a good option as it combines encryption and integrity in one mechanism. " is a bit misleading. GCM uses one after another: 1-st encryption in counter mode and then GHASH to authenticate the data. In the recent intel processors CLMUL-NI is used to speed up the GHASH operations. Benefits of GCM over CBC+HMAC: is much faster, as the ...

1

This sounds like a similar problem addressed by fuzzy extractors/secure sketches. A small excerpt from the abstract: We provide formal definitions and efficient secure techniques for: • turning noisy information into keys usable for any cryptographic application • reliably and securely authenticating biometric data. Our techniques apply ...

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