Backup: same key used for both encryption and authentication?

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

According to many sources, it is insecure to use the same key for both
encryption and authentication/signing.[1][2][3]

Does the Qubes backup system (qvm-backup) do this? I know that the
Qubes backup system uses the same passphrase both for generating the
HMAC and for symmetric encryption (default: AES-256-CBC), but I don't
know enough about cryptography to know whether this entails that the
same key is used for both in an insecure way.


[1]http://security.stackexchange.com/a/2209
[2]http://crypto.stackexchange.com/q/8081
[3]https://en.wikipedia.org/wiki/CBC-MAC#Using_the_same_key_for_encryption_and_authentication

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU11nBAAoJEJh4Btx1RPV8/VsQAJVsCY0VMLRwmM3eUkZ5ieOD
CX4y10BSFP6rQsQOfRgfBr1y0Tt7vudOMwp5E/CFx7xkoqinwBeVgB6Ve+7vmyl/
9T2qy/mbjA7+NE2wT9nUro5cdA52ygTnqmpZxLUHgVE9pCoGEKgHdmIv8jxwbsnP
t7w9D3kMpfqulzVhwmhJDE1q9WU9tYnpwJjsfLdeW5UKcb5AxKAEMKStl5bphsld
fP91OJXLCwsKG3vVF3zhsolr1Y5Sru1asm5RtX371ez8epA0Q0DHAkm+XRVi6lKK
8CSaXvt9+K3USrtT3k7fRQfSAH2eqjzdCEQcyEiZX/4dD4GRgkq0LHw+Q2wzVZIv
GtsCr+f46sczOhokgiKFZTk8pFReEcJ96yYfWXRUmRbUA4d/WZ/7s2sXWZOGPUgx
d9DZ3uc40hBWCEqO9nZHtTwg/71B4w1+6L5/NqTp+iJ7M8itm81C1OMIKmf8GcxX
Jl91Mzdn0LqajAiARiYJWsRzZE02Sfo7Y4m4f0PVqEuleVZesLg/G/eG5uCEetlr
XHCiiGIG1Lh9BbOLmOLyiceP24e0SOiwZoEG9ffC5BLzSeKo1B4m4paUjNM6UZAY
iETK+2l722Z5LzNUYgu8m6YpvKJnWgJKOBwk4kagDxKID4+eerdOMmveMQ4CEuKH
mf5z3s6IjShfQEyBrcSj
=PYdJ
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Axon wrote:
> According to many sources, it is insecure to use the same key for
> both encryption and authentication/signing.[1][2][3]
>
> Does the Qubes backup system (qvm-backup) do this? I know that the
> Qubes backup system uses the same passphrase both for generating
> the HMAC and for symmetric encryption (default: AES-256-CBC), but I
> don't know enough about cryptography to know whether this entails
> that the same key is used for both in an insecure way.

I'm going to attempt to answer my own question.

The Qubes backup system uses the same passphrase both for encryption
and for the HMAC, which is not a good idea from a security
perspective, but also not a fatal problem. This is for two main reasons:

1. There are probably no sufficient interactions between AES-256-CBC
and HMAC-SHA512 such that using the same passphrase for both would
allow for a cryptanalytic attack which would reveal the passphrase.
However, this is more of an intuition held by cryptographers than an
established fact. It is difficult, if not impossible, to define (much
less prove) this in rigorous terms.

2. Hypothetically, if HMAC-SHA512 were broken (or perhaps if our
implementation turned out to be flawed), and this allowed an attacker
to discover the passphrase from the HMAC, the attacker could then
easily decrypt the backup data without even having to attempt to break
or circumvent the AES encryption at all. This seems to be a strictly
unnecessary vulnerability due solely to the use of the same passphrase
for both HMAC and encryption. Of course, it's probably unlikely that
HMAC-SHA512 will be broken (or that our implementation of it is flawed
to such an extent), so this may be a small risk. Nonetheless, it's a
risk we're taking for no apparent benefit. In addition, we should
consider the potential for this presently small risk to be compounded
over time, as Qubes backup archives (some of which may be stored
indefinitely on hostile servers) may be attacked with more advanced
technology in the future.

(See also [4] and [5].)

What ought to be done? There are several options:

3. Use a key-derivation function like bcrypt, scrypt, PBKDF2, or HKDF
with different salts to derive two keys: one for the HMAC, and one for
encryption.

4. Use an authenticated encryption block cipher mode of operation,
such as CCM, CWC, OCB, EAX, or GCM, instead of having a separate
HMAC.[6][7]

5. Use a higher-level API in order to avoid having to "roll our own
crypto" (and potentially make mistakes in the course of doing so).

Comments and corrections welcome.

> [1]http://security.stackexchange.com/a/2209
> [2]http://crypto.stackexchange.com/q/8081
> [3]https://en.wikipedia.org/wiki/CBC-MAC#Using_the_same_key_for_encryption_and_authentication

[4]http://security.stackexchange.com/q/37880
[5]https://stackoverflow.com/q/5235161
[6]https://en.wikipedia.org/wiki/Authenticated_encryption
[7]http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU3G6FAAoJEJh4Btx1RPV8wxIP+wY7mjhvR3uFf3dy7zSA3Jyv
PaLz39H86Ox34+Nh0ZqLX9C9/LFBJUGG9vYNE3m5a5HqZPIMSCfXzNF3uTfhejsD
wIri8gPK/xYmwfFxuXg5SnubnG2j9NILekh1QY3Io7uLS6Aam2pNacJu0Eh5/UHA
fAgALzHqZrwfm/14+dAMOz2NEzQMEyBlishJCB3B7JXwEizeQdvKGYvSpyubL11W
yLdIXl9+lyr9QEVjGHIR6hyxUH2azcMbq+MDlZFOjLpuDFjSjKwTvNXAO5BeSqRf
SsZGhBliriTla3Q6T4GIwdYtF0kCPuHQPKrOtBuQ61TJZR6tkbRHM75Aotem0V2g
J61AhKDfrw1hg3EkETu9g9XTvhTXyCHjpalNKUF3FG1sl7e2O91Vup4HtXE3atTQ
ULfyuu5Y35ClRCWtLPg1iaKoShrTfZg2tptiRSL0nxhb6g1iOQX7FdPeGnZYlGOw
fAulG6UnKPa8Vs8FCyLltqW1S8XCjLMkmX9B9P0rTniCX3uv5TFaDtsrqr5u7V92
OD14u7NnLP73HYkzPFn4VKKCWHiIxX2IlhVFxN+40BwfpEcenPxeWd7eHYu+sMd8
9fNnYugrkfdAWzq6wIwgqQUQLKsIg8sicJOPPO/jUDhKMVNqARQwgmP1U6Ovzokv
hd4Oi0v1jy2FwGWWzTOk
=Klz8
-----END PGP SIGNATURE-----

[Axon]

Here are some more or less explicit warnings against using the same
key for both encryption and authentication:

"...computing the HMAC with a *completely separate* key; e.g., not the
same key you used to perform encryption"[8]

"...on a general basis, use a Key Derivation Function to extend your
encryption key into two keys, one for HMAC and one for the actual AES
encryption (make it three keys: one for the HMAC-for-IV, one for
encryption, and one for the MAC which you *of course* add to the
message to thwart active attackers)"[9]

"...even if (in the case of Encrypt-then-MAC) he can correctly forge
the MAC (say, if he stole the MAC key but doesn't have the Encrypt
key)."[10] (Note: This is from Colin Percival's (creator of Tarsnap)
blog. It's easily the best short piece on "encrypt-then-mac" I've
seen; highly recommended read.)

"Clearly, if you had been using AES-256-CBC for confidentiality and
AES-256-CBC-MAC for authentication, it would not be secure to use the
same key for both confidentiality and authentication. Hence, using the
same key for confidentiality and authentication cannot *generally* be
secure; you need additional premises to arrive at that conclusion. In
your case it would be that the algorithms are "too different" for any
related key attack to be feasible. This assumption is usually
considered to be a bit too shaky for safety, which is why the
established practice, in cases similar to yours when you start with a
single shared secret key, is to derive different keys for
confidentiality and authentication from that shared secret. If you do
that the security of your construct will rest on the assumption that
the KDF you use is a PRF and not on the assumed difference of the
confidentiality algorithm and MAC algorithm."[11]

"... With HMAC vs AES, no such interference is known. The general
feeling of cryptographers is that AES and SHA-1 (or SHA-256) are
"sufficiently different" that there should be no practical issue with
using the same key for AES and HMAC/SHA-1. However, simply defining
that "difference" with any kind of scientific rigor would be hard, and
it is not a much explored security feature. So that's one of these
constructions which can be qualified as "no urgency to fix it, but
don't do it if you can avoid it". A much "safer" way (in the sense of:
"we know what characteristics of the involved algorithms we are
exercising") is to take your master key K, and derive from it, with a
good one-way Key-Derivation Function, a sub-key for encryption and
another sub-key for the MAC...."[12]



And this seems to be another strong reason to start using a good key
derivation function:

"The OpenSSL apps need to be used carefully, they often have old and
possibly insecure defaults, at least by contemporary standards.

In this case openssl enc defaults to using a digest of MD5 (apps/enc.c)

...

The biggest problem here is not the potentially problematic use of
MD5, it's that the KDF that openssl enc uses is "cheap", specifically
it only uses one round, making brute force attacks on passwords the
best attack (apps/enc.c, line #569):

EVP_BytesToKey(cipher,dgst,sptr,
(unsigned char *)str,
strlen(str),1,key,iv);

The sixth parameter to EVP_BytesToKey (hard-coded to 1) is the count,
designed to slow down an attacker (or not, in this case). What
*should* be used instead is a robust, expensive key-stretching
function like bcrypt or scrypt."[13][14]


In other words, "openssl enc" uses a rather weak key derivation
function by default. We can get around the lesser problem of md5 [15]
by using the "-md" option (e.g., "openssl enc -md sha512 ..."). But if
we're going to do that, perhaps we might as well (also) use a proper
key derivation function to initially turn the user's passphrase into
two keys (one for enc, one for hmac). If it's important to stay within
openssl, perhaps PKCS5_PBKDF2_HMAC(_SHA1) is an option?[16] If it's
not important to stay within openssl, bcrypt is probably better, and
scrypt is probably best.[17]

>> [1]http://security.stackexchange.com/a/2209
>> [2]http://crypto.stackexchange.com/q/8081
>> [3]https://en.wikipedia.org/wiki/CBC-MAC#Using_the_same_key_for_encryption_and_authentication
>
>>
> [4]http://security.stackexchange.com/q/37880
> [5]https://stackoverflow.com/q/5235161
> [6]https://en.wikipedia.org/wiki/Authenticated_encryption
> [7]http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html

[8]http://crypto.stackexchange.com/a/5429
[9]http://crypto.stackexchange.com/a/298
[10]http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
[11]http://crypto.stackexchange.com/a/8084
[12]http://crypto.stackexchange.com/a/8086
[13]http://security.stackexchange.com/a/79923
[14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
[15]http://security.stackexchange.com/a/23141
[16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
[17]https://www.tarsnap.com/scrypt.html
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVAYNkAAoJEJh4Btx1RPV8eJIP/R9eSgxTZw3ZqbHlqf/87yDV
M8s6w7qMq0GdFH0Clo1hM9SdDjR/8doGNaEZ3p3Dm+V/A0TL+fbuS29TvvJSpjfW
AuVpOcvjrjdNMKaUQ22uHD9PPgb4MOMhz7YMW1/5fkfqlSzqWOpeJijLs+HELhlE
8HCUwF6YDLm2xCOgIVo3CUIsrwTtUvYVbMAn3oIQXT5tFPB7CqAxniWDwiAIjyyk
zTMTsJlixJYikMmX9EHFAyDa/xflcx/8dkHi89Bbn6lctsLICVwRkgyCX3/PT1RK
8lUZLJEH91PBVyS86GH30N2ABUOwo8IXPWeYHfYrKFx6ibZY8qIxOPIYMCQdDrFp
msZA67xsMXFksSp4g2RPCmKSbDcvgXrLozyrZIwccb6bRdlUt2f84eXYKv0mYPv9
ja3yH/LpVYG+X/2HbpQmEwoC+Wc+JHFRhaANd1aa+vH2g5VyrlmqegC4EQRzLKNZ
/7htGmHo15INeaiU6awteS9Mmxo8NtWuWX0Btb+PuGFsgmXs/0budce/FzL4lglh
DNJhtWF7xsAJIR7X1hHEcUFnHyI2VXWDlmpbtPxKs9klyBQU4f8EcFNA96aETABn
J4mhbhcUipNKy1O23ZJp0C3mZALlPiiBPgusQnargaFDXPTrYlkWOVDk/S1hZfQN
gx3Z21oWe0RNSxiqll0J
=fZWi
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, so assume we want to use scrypt:
scrypt(Passphrase,Salt,N,p,dkLen)[18]:
MFLen - Length of block mixed by SMix() , in octets.
hLen - (32) Length of output produced by HMAC_SHA256() , in octets.
dkLen - Intended output length in octets of the derived key; a
positive integer satisfying dkLen ≤ (232− 1) * hLen.
N - CPU/memory cost parameter.
p - Parallelization parameter; a positive integer satisfying p ≤
(232− 1) * hLen / MFLen.

Passphrase and dklen are obvious. Standard value of p is 1. The
question how we choose N and salt. As for N, I see two options:
1. Static value (for example python module uses 16384 by default)
2. Calculated dynamically to make the whole operation running some
predefined time - like 1s

The same applies to salt:
1. We can use static values - one for hmac, the other for encryption, or
2. We can choose two random values at backup creation

Of course dynamic options give better security, but the problem is how
to get them during restore process. We have a backup header, but it should
be accessed only after its HMAC verification. But to verify its HMAC we
need a key...

There is an option we rewrite backup header parser to carefully sanitize
all the data (at least those needed to calculate key for HMAC
verification), but I'd rather avoid that.

Any ideas?

> >> [1]http://security.stackexchange.com/a/2209
> >> [2]http://crypto.stackexchange.com/q/8081
> >> [3]https://en.wikipedia.org/wiki/CBC-MAC#Using_the_same_key_for_encryption_and_authentication
> >
> >>
> > [4]http://security.stackexchange.com/q/37880
> > [5]https://stackoverflow.com/q/5235161
> > [6]https://en.wikipedia.org/wiki/Authenticated_encryption
> > [7]http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html
>
> [8]http://crypto.stackexchange.com/a/5429
> [9]http://crypto.stackexchange.com/a/298
> [10]http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
> [11]http://crypto.stackexchange.com/a/8084
> [12]http://crypto.stackexchange.com/a/8086
> [13]http://security.stackexchange.com/a/79923
> [14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
> [15]http://security.stackexchange.com/a/23141
> [16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
> [17]https://www.tarsnap.com/scrypt.html

[18]https://en.wikipedia.org/wiki/Scrypt#Algorithm

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVPpZ3AAoJENuP0xzK19csalsH/1Izoy6c+wHgDRk/PN9tmeVM
70MByduXts1n9iq5t0AlWsF78dtHq6L5+hmfK8Pu/aWYzLsbjlCYXU006aZ0u1Wa
YQLbZivXBhAlcp4d6GEVKqfebR8s/KTRqg3/bb6TxyYhgIA12VhhJz7wjX0F8RqQ
qRnfxJuCPn5v9XnbNx5N/HBBQFlET6IR9Ye+GZBuM6q03ajVNkXrb2DUWYgPW2Ec
MghBkAoC1ErDdH9hny5TNT/Qj24ZVy33Tl8maAYYPWZdmbAISjDR1/Kg6k3cMQRz
flkoZK57p6Gjxk7GPvalOEVh23Z6TAUL/lCGkmTp0ES+EZ/BhnB91gFM8Wny2Xs=
=4G5B
-----END PGP SIGNATURE-----

[Andrew]

Marek Marczykowski-Górecki:

Why not just start with some sane static value for N (e.g. 16384), and
keep trying the double of the last value, until the HMAC works. This
means N should always be a power of two; see the dynamic scaling code in
scryptenc.c. But you can still use dynamic scaling, or allow it to be
user-configured.

This changes the decrypt/verify time, of course: instead of doing N
work, we do almost 2N work. It also has the "black hole" "problem": if
a user's password is incorrect, it will just keep trying higher and
higher N forever.

Maybe a static maximum for N could help? Or just warn when going above
a certain maximum N value? Or, if we're restricting the range of N so
severely anyway, just use a sane value for N tuned to ~10s on current
hardware.

Andrew

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually this will be the second thing guessed - we already guess hash
algorithm this way.

> Maybe a static maximum for N could help? Or just warn when going above
> a certain maximum N value? Or, if we're restricting the range of N so
> severely anyway, just use a sane value for N tuned to ~10s on current
> hardware.

That can be dangerous assumption. Imagine the situation then user's
primary machine fails and the user tries to restore the backup on backup
hardware, which is much older. Then such limit can be easily achieved.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVPqBvAAoJENuP0xzK19csxuwH/j4NJqZmxzg7Hvddc/1YnTjT
q4ZA+qOWGeqiok9K/f5BK05rowOSChuuqB5epBuFynNbAEOW05etGjVR5rxab2yc
0jdmxOsoWstWLo5g/hmYLoLB32Rfgb77U0UdWhvmIy7t2UdAgYEODKFqA6CZgAek
LgOkOvveDFdjN9tiIx3lD6Fw4f0TaWmcQpE4TLZMRHPPWj6n08fTCHhGINhMDBUq
8Ahx26fwk/my+nVm7VBDOw86BCxd2BqzJtG1Y1didXROYwS7JNBb7+2wZJHtNFxA
vKzlwLpq42un+O2BZ583s8OCOOUA4ZJ/+q5XQyqjfbpSPpv6aedXPd/hZYtvVJo=
=b1NS
-----END PGP SIGNATURE-----

[Andrew]

Marek Marczykowski-Górecki:

Sorry, just to be clear: I meant use a static maximum N value, the same
across all machines. Not a static maximum N determined dynamically
per-machine.

Is there any reason to use a different hash function? Just for
future-proofing?

Andrew

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I see. That can work.

> Is there any reason to use a different hash function? Just for
> future-proofing?

Yes, exactly.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVPrJGAAoJENuP0xzK19csXpgH/ArivebZZfJM5+MwRWpuEmhU
FfTvg2XkRrYiqxMgSh/R/msnSOYKf+fdIJlixCiEdAabqlzWRxQSOoILAAzUDfm+
fCojQLIWFrjngvbd5IlYYuT0lMVbVqurvrrinnHsMTkIwDM8APjkgU5rUE45HM8D
uEC57Fw0/Cx5ko5FdKUkDM0ZzNBhHDC9BzMZoJZp4686RWub5avGz+7DKTiE8qGu
mbCsLTLYbmn+xA4jJNid64IcpCGGVZ1JOWB8G7RGaubM4CUpey3m+u3Kg4HHD7Kz
qJiGZKQkRolM45dEHERtYdUxTiJhFc9rvzNZUXgd8Vx4zPpl3LoBfvf7I54YUe8=
=YM3p
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Axon:

Don't mind me. Just adding more fuel to the fire. :)

I've been noticing several comments like these:

"Don't use the openssl command for serious work. It's meant only as a
showcase of the library functions, and it's badly designed even for
that."[18]

"Careful. Openssl enc is basically a poor toy example, it's not a
robust authenticated encryption tool for real world use."[19]

Can anyone point me toward relevant sources for this? Is this just
common knowledge? Do people just have an unwarranted grudge against
openssl?

>>> [1]http://security.stackexchange.com/a/2209
>>> [2]http://crypto.stackexchange.com/q/8081
>>> [3]https://en.wikipedia.org/wiki/CBC-MAC
>>> #Using_the_same_key_for_encryption_and_authentication
>>>
>> [4]http://security.stackexchange.com/q/37880
>> [5]https://stackoverflow.com/q/5235161
>> [6]https://en.wikipedia.org/wiki/Authenticated_encryption
>> [7]http://blog.cryptographyengineering.com/2012/05/
>> how-to-choose-authenticated-encryption.html
>>
> [8]http://crypto.stackexchange.com/a/5429
> [9]http://crypto.stackexchange.com/a/298
> [10]http://www.daemonology.net/blog/
> 2009-06-24-encrypt-then-mac.html
> [11]http://crypto.stackexchange.com/a/8084
> [12]http://crypto.stackexchange.com/a/8086
> [13]http://security.stackexchange.com/a/79923
> [14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
> [15]http://security.stackexchange.com/a/23141
> [16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
> [17]https://www.tarsnap.com/scrypt.html
>

[18]https://askubuntu.com/a/647703
[19]https://news.ycombinator.com/item?id=9966661
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWKMEjAAoJEJh4Btx1RPV843YQAPcLCGjfIZGZ+Vwhk7fRs4dV
PW1p4X+byI3KE0Wy4+3gTEDB2G9FPGePcbOkZH79/XR2qawuDyWLgSg/k+HwyZx6
Hd9NiBFEjebNgFCBOr/7WBf3iWxTv2ZzG8nggTtBnzNWVNyIBIX4IOZgTUSlRa2W
qrS2hlxjB+0fSqs2nGEVmmimJjTcvyn86Mg120WKaMS4jmX4qptgJohpgKuJvWHI
UE/Nwp0bYOjbPlyG/FCHIOyEsWPHcQwFFC+0SiujS2YZBwpgV08uwjOumeT4+sRH
7E4Xvmz3+rN4I3Ll5yIWoWXzALsFOFMDTpK+KsQzjzXSV/F0V1hPykRTalGAZcp8
B0vD7pU2pcA54YHsa55NvkY7WELJH3AWOCMQS6AIkt7bSrsTZDig/BWAa+EfYI2x
afVJ+deOWT5VbLXzeQsYsqA2omnYse1hyuOJ3lM+AcX+Moo+mDx0tni9YQYVbFHG
d0rharx0P8whg4/mMylSNjUDJu02WKj6V51B4QvnmAeOTsX+NdaP9oeEpY/uk3Qs
dmlqYoEEevS+lKzYpqSYZR5quPfwga5R+/Yjqv0Hz1RBHI1/gHqL7TDScQ5U19gK
79PDTeZKZlicCPfzq1vo53xJBEdoV/6pfACL0y1fyh8POgD1y038CDvHEzHhf8jn
i1YR0hegKLDO7W1NQBKe
=rIhG
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Reading some of its source code I have the same feeling... It can be
useful, but needs to be used with care. Do you know any alternative?
Preferably separate tool (not a python library) to not sacrifice
performance.

> >>> [1]http://security.stackexchange.com/a/2209
> >>> [2]http://crypto.stackexchange.com/q/8081
> >>> [3]https://en.wikipedia.org/wiki/CBC-MAC
> >>> #Using_the_same_key_for_encryption_and_authentication
> >>>
> >> [4]http://security.stackexchange.com/q/37880
> >> [5]https://stackoverflow.com/q/5235161
> >> [6]https://en.wikipedia.org/wiki/Authenticated_encryption
> >> [7]http://blog.cryptographyengineering.com/2012/05/
> >> how-to-choose-authenticated-encryption.html
> >>
> > [8]http://crypto.stackexchange.com/a/5429
> > [9]http://crypto.stackexchange.com/a/298
> > [10]http://www.daemonology.net/blog/
> > 2009-06-24-encrypt-then-mac.html
> > [11]http://crypto.stackexchange.com/a/8084
> > [12]http://crypto.stackexchange.com/a/8086
> > [13]http://security.stackexchange.com/a/79923
> > [14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
> > [15]http://security.stackexchange.com/a/23141
> > [16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
> > [17]https://www.tarsnap.com/scrypt.html
> >
> [18]https://askubuntu.com/a/647703
> [19]https://news.ycombinator.com/item?id=9966661
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWKO/lAAoJENuP0xzK19csPBYH+gKuFhDGkTJyo+s1TuO34K7H
JEZQeUikmPtDa4MVPPAQtyqTFQxIu8AYJoUm6RPavBo6t6hdJCFIcM+6yrJTQY0G
OUAmJOhS7BIG/bprFLiRNd3O4uncyHMr463i5XHhYPGiu2XQGm15R/ZpbtPBq9nY
5NAQa7kZwT7lk5qvyzZp78cEkX8FYJYMiiD0nnm1LCks0S84/qJoU5tXm4ewxqtQ
knFsAXCaX6tc0q7FOKiufwIKG4raC/zVAq+LVtvCpqfdk7+AVn7XnsCnvNnIOI7K
O/ruzQoIjdIvYEff3vu5i9DEUee1xvqAw4XDbCOg2tOTht1YHnrZDXZEVdwndnI=
=vj6R
-----END PGP SIGNATURE-----

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

I don't know if there exist small minimalistic command line tools like
the openssl cmdline stuff. But regarding crypto libraries most people
recommend libsodium [20] for such task.

>>>>> [1]http://security.stackexchange.com/a/2209
>>>>> [2]http://crypto.stackexchange.com/q/8081
>>>>> [3]https://en.wikipedia.org/wiki/CBC-MAC
>>>>> #Using_the_same_key_for_encryption_and_authentication
>>>>>
>>>> [4]http://security.stackexchange.com/q/37880
>>>> [5]https://stackoverflow.com/q/5235161
>>>> [6]https://en.wikipedia.org/wiki/Authenticated_encryption
>>>> [7]http://blog.cryptographyengineering.com/2012/05/
>>>> how-to-choose-authenticated-encryption.html
>>>>
>>> [8]http://crypto.stackexchange.com/a/5429
>>> [9]http://crypto.stackexchange.com/a/298
>>> [10]http://www.daemonology.net/blog/
>>> 2009-06-24-encrypt-then-mac.html
>>> [11]http://crypto.stackexchange.com/a/8084
>>> [12]http://crypto.stackexchange.com/a/8086
>>> [13]http://security.stackexchange.com/a/79923
>>> [14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
>>> [15]http://security.stackexchange.com/a/23141
>>> [16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
>>> [17]https://www.tarsnap.com/scrypt.html
>>>
>> [18]https://askubuntu.com/a/647703
>> [19]https://news.ycombinator.com/item?id=9966661

[20]: https://github.com/jedisct1/libsodium
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWKPYrAAoJEOSsySeKZGgWv0YP/1S8L6Jh8CPhTmXXxjGQHOer
XhVzQ8U7+HlhmnjvxrtnmYf3JMus3HeaHvVYEE1/Pvq9dyUt3YuqqD5JIIKvD+kW
mTlCnY8e51kFbgbd2/27jXHU3MM9CaPAwV/Q93tsfLb8K/BHtJMNrD4h0Ca4GDOf
68wV7Fa3gFh0wdqa3pnkhBQhd3PTiaAYWhGUTw1ovPwVxsRN9FnDK+OCGh/p2DkD
tOxWsdmVm6pr64ZB21c+EEInCn4j++K0QuESkoZeObDi/p1obzL9YwRo1v5IPj7J
ieKqWOfdlRraUl62Zw9HD6GkRCdswHcbg9ZEcm14cjxdAKxDSunQ4l+2aobQ8KrA
dUb+AMvNeuvzaiSikjgky/8uHpPv3SyGcoo4u9oYziss4y6e+zI+1QOWkD9+pP6c
oxbRELSCj9CO/5oqKuJa1h5cZuqZSqHM3ZSp/8SEQJNakVgx3g1shbjE2845C7IF
ikcSEUf8+I6UoullgS+sU6C/Um73eN9HbGac+ngztWPvW+mC4h+GxP/gIQbgMLD+
EnXJiDLTtg6fTsVjMBB86nyhEE4L8xbFaTNkZH5eQfn0eavoirxipw345VCFCwm2
I3t4j/SMCg8pFsPVFnPKanANZyZhABBcXuH1lazeq/yf1BvQEaKHN13qK/LwTgf7
uGnPzoi5LcLUZ4hI4cuE
=KsDA
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

HW42:

I'm not personally aware of anything that would function well as a
drop-in replacement for OpenSSL (in terms of being ubiquitous and
time-tested) except for GPG. Recall that we originally rejected GPG
for the backup system because it did too much parsing of the data
before verifying its integrity.

Joanna (2013-03-28) [21]:
> So, we see that gpg first parses the blob significantly before
> first verifying its integrity. This sounds like a very bad idea to
> me, as it exposes many code paths in the GPG to an attack if the
> blob was intentionally malformed.
>
> So, I would suggest to use openssl dgst -hmac to verify the
> integrity of the blob first, and only then to pass it to GPG for
> decryption. Or perhaps we can also use openssl to handle the
> decryption? Doesn't sound like a critical decision, but I think it
> would be more elegant to stick to just one crypto framework --
> openssl in that case.

So, we considered the possibility of using OpenSSL for
integrity-verification, then using GPG for encryption. However, it
looks like we decided against this and opted for using only OpenSSL
since it didn't seem to matter which tool we used for encryption (and
in that case, we might as well just use one). However, we now have
reason to believe that OpenSSL handles encryption much more poorly
than integrity-verification in our application. Therefore, we should
perhaps reconsider using GPG for encryption (while keeping OpenSSL for
authentication).

> I don't know if there exist small minimalistic command line tools
> like the openssl cmdline stuff. But regarding crypto libraries most
> people recommend libsodium [20] for such task.
>

I, too, have often seen NaCl and libsodium recommended. Seems like one
of those would be a good way to go (if going with a library).

>>>>>> [1]http://security.stackexchange.com/a/2209
>>>>>> [2]http://crypto.stackexchange.com/q/8081
>>>>>> [3]https://en.wikipedia.org/wiki/CBC-MAC
>>>>>> #Using_the_same_key_for_encryption_and_authentication
>>>>>>
>>>>> [4]http://security.stackexchange.com/q/37880
>>>>> [5]https://stackoverflow.com/q/5235161
>>>>> [6]https://en.wikipedia.org/wiki/Authenticated_encryption
>>>>> [7]http://blog.cryptographyengineering.com/2012/05/
>>>>> how-to-choose-authenticated-encryption.html
>>>>>
>>>> [8]http://crypto.stackexchange.com/a/5429
>>>> [9]http://crypto.stackexchange.com/a/298
>>>> [10]http://www.daemonology.net/blog/
>>>> 2009-06-24-encrypt-then-mac.html
>>>> [11]http://crypto.stackexchange.com/a/8084
>>>> [12]http://crypto.stackexchange.com/a/8086
>>>> [13]http://security.stackexchange.com/a/79923
>>>> [14]https://www.openssl.org/docs/crypto/EVP_BytesToKey.html
>>>> [15]http://security.stackexchange.com/a/23141
>>>> [16]https://www.openssl.org/docs/crypto/PKCS5_PBKDF2_HMAC.html
>>>>
>>>>
[17]https://www.tarsnap.com/scrypt.html
>>>>
>>> [18]https://askubuntu.com/a/647703
>>> [19]https://news.ycombinator.com/item?id=9966661
>
> [20]: https://github.com/jedisct1/libsodium
>

[21]https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWKZCIAAoJEJh4Btx1RPV8QK0P/RavFUEMwqF9FIAJfMKm82yt
fRTIXZDyjN5rS/SZvoR4IUqOkbrnRDfuzzNtHfnBBMEuXZQ4Er0bjgfOOESG9p4Q
m/eDNa0HqWQpQ7DZCR6oc0t0/tBW+87trkWW/AKZUQPGeUbRbLHTHAmeCG8+F9UH
TM2KRQOAz4WJqqFidGjLu6gx8hk7vhwkfjYbIY+FsUHsoCp9PP+yh99TAg+/n7Zq
0O0KVU0Rw3lVcyoOgumcCntJ7scvR9lduZh5bE9NvfzNh1Nm8SEJC5SV4MJ9heSl
+yoco7aucMbavVNLiDdUm9w183YwLm3O27luM681vhu8qp27NNmTy9gi5QkalbUe
+JH/Esxu/+6MPI8PwpEGJxxU3E6M0RJrSGbYngBz37zdZN/l96HxCLX0sFliKKDH
2tYlhAIwyaMV8avp2UD+5EbTB+iXjUxptO/eNfA8tl8q1PReKPiazqOh+59Lo6Nq
bwwOCC05cX/ar17gH5zMb3yKE17FG6rjdTJVKi3y9SatiNCQpu/hjM9w6YmtSVxb
N+yg9x4hhim1yORskECVfnII48dSPR10MsUEsm1ZVcR7dupUUPkMzABsONsLwtoo
k0lYX3V7HncukIXK3EhBwVf6EjPBqxdW5yZj5IwC84/+W96i5zl1fo8afS8lZZBF
UvHxEi0VwekCaKU/xeIl
=XNMl
-----END PGP SIGNATURE-----

[Andrew]

Axon:

I'm coming back to this thread without having read all the responses in
the meantime, but is there a particular reason (or are there some
particular reasons) why not to use Colin Percival's previously-mentioned
scrypt[0]? Keep in mind he published two things: 1) the KDF, and 2) a
tool using it. I'm talking about the tool.

Obviously it uses the scrypt KDF to derive AES and SHA256-HMAC keys,
then [en/de]crypts the file and writes/checks the HMAC of the plaintext.
It's pretty bare-bones (so hopefully has a small attack surface),
written by a well-known and -respected security professional, and seems
to do almost exactly what we want.

It does not produce an HMAC of the ciphertext, so there is some
theoretical risk from processing malicious input, but in my
unprofessional estimation this risk is low.

Andrew

[0]: https://www.tarsnap.com/scrypt.html

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The reason why we have openssl instead of gpg for integrity check is
exactly that we want to verify it before any other processing of the
content. But as for the tool itself, I'll look into it. Previously I've
checked only the library with the KDF itself.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWKkv1AAoJENuP0xzK19csmaoIAIyLbeNdJJ0JEXIBhvZraDU3
LXkgOt/RitHL9iT8+Ew+dzVQoiUcIVjoqBuryHos5uN0vPIVK3390GDChMvrgRMA
yHGx0hG4oxAdMW504QQVqjwOAE1ZPXyxQuAaZFBovR1R0Eng8PFgPuOY5ofWxDjn
NP87ulJOlhB+8OO7Y3RhDEYc0GkfJMrNsHJENAD9x4sOzpDmeIodzO02ZOfyHyrG
Qp0ODBaFM07Ro5DljFZVCUrupmpqqVBQRGby7FvB47VF441Md2lyjGuKiPbSZZZv
NwbyaCMYb3GrwVVAo2j00DwlzP1w6yJaH4dxLDAm3jpVF3GBFAjRDEWcMpCMtZo=
=r5oq
-----END PGP SIGNATURE-----