Return to Answer

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.)

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.)

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.)

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.)

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.)

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.)