# Simplified Key Wrapping to Achieve Only Confidentiality?

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.

-
Can we assume the 'password' has $n$ bits of entropy (rather than simply being $n$ bits long)? –  figlesquidge Apr 27 at 20:50
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. –  D.W. Apr 28 at 4:36
@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. –  beewoolie Apr 28 at 16:24

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.
I do not mean guessing W'. $\:$ See my updated answer. $\;\;\;\;$ –  Ricky Demer Apr 28 at 4:02
Yes, although I noticed that I can cut down on the number of lines, so I removed two of them. $\hspace{.77 in}$ –  Ricky Demer Apr 28 at 8:47