# Tag Info

8

This is impossible for any generally useful hash: a hash must map all inputs to a fixed-length output, but you normally want to be able to take variable (and fairly long) inputs. The problem is that there are more inputs than outputs: you normally want to be able to hash any string up to a fairly big length, but the hash itself should not be too long, and ...

4

Well, if the hash function is weak, then the attacker might be able to take a valid signature for a signed message, and find a second message for which the signature for this first would also validate for the second. For example, if Alice signs the message "I like chocolate", what Bob might do is find a second message "Alice owes Bob $13,106,107.57", and ... 3 What you are looking for reminds me of one-way accumulator functions [1]. Basically, a one-way accumulator permits to prove the membership of an element$x$to a set$S$without revealing the actual members of the set. See for example this definition from [2]: The most common form of one-way accumulator is defined by starting with a “seed” value$y_0$, ... 2 As CodesInChaos pointed out, the major flaw with this is that filenames aren't unique. If you did this on a large scale, anyone who's been given a key for a filename could decrypt any file with that filename. Even if the contents of the file are different, and they weren't intended to be given access to that file. Here's another solution that has one unique ... 2 Yes, it's safe, as you can't calculate the secret key from the HMAC result. HMAC would be useless without this feature No, Bob will not be able to use his key to calculate the other keys, as long as you use a reasonable hash function (SHA-2 should fit) It's the same as 1., Bob doesn't get more information by more derived keys But when Bob get the key for ... 2 Yes they are called Perfect hash functions on wiki. If you follow the link at the bottom of the page there are links to articles and source code. Logically they do not have fixed length output. 2 That's true. There should not be any publicly known attack on SHA-1 that allows for a given$d1$to find a$d2$such that$h(d1) = h(d2)$. SHA-1 is vulnerable for finding a pair of$d1$and$d2$such that$h(d1) = h(d2)$. The same, however, applies to MD5, which is unusable for SSL/TLS certificates and a successful attack has been performed. So, this kind ... 2 RFC 4492 specifies ECC for TLS1.0 and TLS1.1. It does not cover TLS1.2 because it was written before TLS1.2; notice that 4492 is less than 5246. RFC 5246 TLS1.2 changes the signature structure for all signing algorithms including ECDSA, and also adds a Hello extension to negotiate supported signing algorithms (including hash) more flexibly. RFC 5246 A.7 ... 2 The expected effort to find$k$distinct collisions on an ideal hash function of output size$n$is about$\sqrt{2k} \cdot 2^{n/2} = \sqrt{k2^{n+1}}$(for$k << 2^{n/2}$). One way to see this is to look at the probability of the outputs of two distinct inputs colliding, which is$2^{-n}$; if we generate outputs for$\sqrt{2k} \cdot 2^{n/2}$distinct ... 1 You are right that the padded message by itself is ambiguous. But the Blake2 compression function does not just take the message block and the chaining value as input. It also takes a finalization flag (to mark the last block and prevent length extensions) and the message size in bytes. Passing the size to the non final blocks mainly serves to prevent ... 1 This preprint of the article published in the proceedings of ACNS 2013 on the official website of BLAKE2 contains on site 15 the answer in a description of the differences between BLAKE and BLAKE2: Simplified padding. The new padding does not include the message length of the message, unlike BLAKE. However, it is easy to see that the length is ... 1 While OAEP uses a one-way function on the plaintext, it's not quite a hash: it's called a mask generation function (MGF), and unlike a hash it can produce as much or as little output as you want (the output length is an argument to the function, and input length is decoupled from output length). This output should be pseudorandom. You use this in a ... 1 There exist many standards which describe a lot of padding modes and security protocols. If you're new in that field, I strongly recommend you to study the family of PKCS standards which are the reference in the domain. There also exist other distinct standards depending of very specific application fields (Banking, mobile, Cloud, Embedding ... or Global ... 1 Alternatively, let$H$be a hash function (in the ordinary sense) from the input space to$[0,2^N)$for some$N$, and for$0 \leq x < 2^N$let$f(x)$be the smallest prime greater than$2^N + x$. (Here$N$is determined by the security parameter. You can have 'probable prime' instead, where the precise definition of that will also depend on the security ... 1 No, you don't have to convert to a 32-bit string. A "32-octet octet stream" means an octet stream with a length of 32 octets. An octet stream is also known as a byte array. In older times bytes could have different lengths (7 or 9 byte lengths have existed). An octet is always 8 bits; nowadays octets and bytes should be considered synonyms. So basically ... 1 I can propose this (just invented it on paper): ($h$is some hash function, like SHA1,$||$is concatenation,$+$is usual sum (xor is ok too)): H1(a, b) = (h(a) + h(b)) || h(h(a)) || h(h(b)) For H2, either from$a$or from$b$we can derive the all$h(a), h(h(a)), h(b), h(h(b))$and check the hash. Also, if we assume that input pair is not ordered, to ... 1 You are right about the interpretation of the power 10: it's a tenfold iteration. So we apply the function 10 times, starting with$x$, feeding the output as input for the next step. So C-like (I write x for the vector of 16 words$x_0,\ldots,x_{15}$): y=x; for (i=0; i< 10; i++){ y = doubleround(y) }; return y The inverse of little-endian is ... 1 Yes.$\:$However, note that also using$K$in the ordinary way would be a huge vulnerability, since learning$H(K,m_1)$would allow anyone to authenticate$m_1$together with arbitrary messages$m_2$. The two solutions$H(K,$prefixfree$\hspace{.02 in}(m_1)\hspace{.02 in}||\hspace{.02 in}m_2)$and if$\: \operatorname{length}(m_2) < ...

1

If the hashing function $H$ is secure, then $H(H(K, m_1), m_2)$ is secure. But at the cost of applying $H$ twice.

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