2
$\begingroup$

I'm looking for help in understanding why the algorithm described here would not deliver adequate protection of confidentiality. We don't care about other criteria such as authenticity or integrity. In other words, we only want to make sure our key material is secret.

Given a key $k$ that is $l$ bits long, a hashing algorithm $H$ that produces an $l$ bit digest, a password $p$ of at least $n$ bits (smaller than $l$), and a randomly generated $l$ bit salt $s$, we produce an $l$ bit wrapped key $W$ by:

$$\begin{align} W &:= H(s||p) \oplus k &\text{(Wrap)} \\ k' &:= H(s||p) \oplus W' &\text{(Unwrap)} \end{align}$$ where $W'=W,k'=k$ if the transmission has not been tampered with (nb: we do not care if it has).

We know that authenticated encryption would be better. At this time hashing is our only tool.

Are we falling prey to a fearsome Birthday Attack?

It appears that a related question was asked before though they were more ambitious and the answer isn't clear.

Hash Based Encryption (fast & simple), how well would this compare to AES?

Update (28 Apr): As my goal is to help eliminate some of the confusion, I'd like to amplify the answer. I'm reading that malleability refers to the relatedness of ciphertexts, vis a vis Dolev, Dwork, Naor. Specifically, we know that a certain number of bits in the ciphertext need to be inverted to recover the key. We're also pretty certain that that all of the bits need to be inverted thereby reducing the search space. The relationship between malleability and the chosen-ciphertext attacks is well known.

FWIW, if AES were available there would be no reason to consider anything other than one of the established key wrapping algorithms such as the NIST AES KeyWrap.

To summarize, the intention of using a hash function in the proposed construction is to build a reversible transformation from an inherently non-reversible function. Because of the malleability introduced by the XOR there is no number of iterations of the hash to slow the pace of a brute-force search that would compensate for the fundamental weakness of the algorithm.

Many thanks.

$\endgroup$
3
  • $\begingroup$ Can we assume the 'password' has $n$ bits of entropy (rather than simply being $n$ bits long)? $\endgroup$ Commented Apr 27, 2014 at 20:50
  • $\begingroup$ Ignoring authenticity/integrity is a really bad idea. It has led to successful attacks on confidentiality in the past. I strongly recommend against this sort of thing; use authenticated encryption or an authenticated key wrap algorithm that does provide integrity + authenticity. $\endgroup$
    – D.W.
    Commented Apr 28, 2014 at 4:36
  • $\begingroup$ @D.W. By the way, the reason for my question is precisely the kind of advice you are giving. Many contributors offer words of caution and general advice. Ricky Dermer's response adds something substantial to the discussion so that we don't see the same questions repeated. $\endgroup$
    – beewoolie
    Commented Apr 28, 2014 at 16:24

1 Answer 1

1
$\begingroup$

Your proposal is malleable, so in particular, confidentiality does not hold against a chosen-W' attack, which is the key-wrap analogue of a chosen-ciphertext attack. $\:$ Also, the fact that your
proposal concatenates s with p suggests that H can probably be evaluated too quickly.
Although that may be typical, it shouldn't be, since the time needed to try passwords
in a known way scales linearly with the time needed to evaluate the password hash.
This answer gives some better password-based key derivation functions.

The "best reason that it is better for key wrapping" is that AES is hopefully non-malleable.
(Note that AES should replace xor, rather than replacing H.)

$\endgroup$
5
  • $\begingroup$ What do you mean by malleable? The specific hash isn't chosen nor is the length l? What is a "chosen W'" attack? Do you mean guessing W'? I don't understand what you mean about contenation of s and p. As far as I have ever seen, that is a typical method for sending a password through a hash. link. So while I can see that the expense of computing something like AES is going to much greater than SHA256, is that really the best reason that it is better for key wrapping? $\endgroup$
    – beewoolie
    Commented Apr 28, 2014 at 1:44
  • $\begingroup$ I do not mean guessing W'. $\:$ See my updated answer. $\;\;\;\;$ $\endgroup$
    – user991
    Commented Apr 28, 2014 at 4:02
  • 1
    $\begingroup$ @RickyDemer: did you mean to put in all the strange new-lines through your answer? It renders very strangely for me $\endgroup$ Commented Apr 28, 2014 at 8:22
  • $\begingroup$ Yes, although I noticed that I can cut down on the number of lines, so I removed two of them. $\hspace{.77 in}$ $\endgroup$
    – user991
    Commented Apr 28, 2014 at 8:47
  • 2
    $\begingroup$ What is the reasoning for them? It makes it look very strange on other size windows (eg the android app, my browser here). $\endgroup$ Commented Apr 28, 2014 at 9:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.