[147550] in cryptography@c2.net mail archive
Re: [Cryptography] AES-256- More NIST-y? paranoia
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Mon Oct 7 11:52:22 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
Date: Mon, 07 Oct 2013 11:45:56 -0400
To: nico@cryptonector.com
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============5710207578816997618==
Content-type: multipart/alternative;
boundary="Apple-Mail=_F896AE62-D666-44FC-8B86-9DEEB6331788"
--Apple-Mail=_F896AE62-D666-44FC-8B86-9DEEB6331788
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
If we are going to always use a construction like AES(KDF(key)), as Nico =
suggests, why not go further and use a KDF with variable length output =
like Keccak to replace the AES key schedule? And instead of making =
provisions to drop in a different cipher should a weakness be discovered =
in AES, make the number of AES (and maybe KDF) rounds a negotiated =
parameter. Given that x86 and ARM now have AES round instructions, =
other cipher algorithms are unlikely to catch up in performance in the =
foreseeable future, even with an higher AES round count. Increasing =
round count is effortless compared to deploying a new cipher algorithm, =
even if provision is made the protocol. Dropping such provisions (at =
least in new designs) simplifies everything and simplicity is good for =
security.
Arnold Reinhold
On Sat, 5 Oct 2013 19:37, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Oct 4, 2013 at 11:20 AM, Ray Dillinger <bear@sonic.net> wrote:
>> So, it seems that instead of AES256(key) the cipher in practice =
should be
>> AES256(SHA256(key)).
>=20
> More like: use a KDF and separate keys (obtained by applying a KDF to
> a root key) for separate but related purposes.
>=20
> For example, if you have a full-duplex pipe with a single pre-shared
> secret key then: a) you should want separate keys for each direction
> (so you don't need a direction flag in the messages to deal with
> reflection attacks), b) you should derive a new set of keys for each
> "connection" if there are multiple connections between the same two
> peers. And if you're using an AEAD-by-generic-composition cipher mode
> then you'll want separate keys for data authentication vs. data
> encryption.
>=20
> The KDF might well be SHA256, but doesn't have to be. Depending on
> characteristics of the original key you might need a more complex KDF
> (e.g., a PBKDF if the original is a human-memorable password). This
> (and various other details about accepted KDF technology that I'm
> eliding) is the reason that you should want to think of a KDF rather
> than a hash function.
>=20
> Suppose some day you want to switch to a cipher with a different key
> size. If all you have to do is tell the KDF how large the key is,
> then it's easy, but if you have to change the KDF along with the
> cipher then you have more work to do, work that might or might not be
> easy. Being able to treat the protocol elements as modular has
> significant advantages -and some pitfalls- over more monolythic
> constructions.
>=20
> Nico
--Apple-Mail=_F896AE62-D666-44FC-8B86-9DEEB6331788
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>If we are going to always use a construction like AES(KDF(key)), =
as Nico suggests, why not go further and use a KDF with variable length =
output like Keccak to replace the AES key schedule? And instead of =
making provisions to drop in a different cipher should a weakness be =
discovered in AES, make the number of AES (and maybe KDF) rounds a =
negotiated parameter. Given that x86 and ARM now have AES round =
instructions, other cipher algorithms are unlikely to catch up in =
performance in the foreseeable future, even with an higher AES round =
count. Increasing round count is effortless compared to deploying a new =
cipher algorithm, even if provision is made the protocol. Dropping such =
provisions (at least in new designs) simplifies everything and =
simplicity is good for security.</div><div><br></div><div>Arnold =
Reinhold</div><div><br></div><div><br></div><div>On Sat, 5 Oct 2013 =
19:37, Nico Williams <<a =
href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com</a>> =
wrote:<br><blockquote type=3D"cite">On Fri, Oct 4, 2013 at 11:20 AM, Ray =
Dillinger <<a href=3D"mailto:bear@sonic.net">bear@sonic.net</a>> =
wrote:<br><blockquote type=3D"cite">So, it seems that instead of =
AES256(key) the cipher in practice should be<br></blockquote><blockquote =
type=3D"cite">AES256(SHA256(key)).<br></blockquote><br>More like: use a =
KDF and separate keys (obtained by applying a KDF to<br>a root key) for =
separate but related purposes.<br><br>For example, if you have a =
full-duplex pipe with a single pre-shared<br>secret key then: a) you =
should want separate keys for each direction<br>(so you don't need a =
direction flag in the messages to deal with<br>reflection attacks), b) =
you should derive a new set of keys for each<br>"connection" if there =
are multiple connections between the same two<br>peers. And if =
you're using an AEAD-by-generic-composition cipher mode<br>then you'll =
want separate keys for data authentication vs. =
data<br>encryption.<br><br>The KDF might well be SHA256, but doesn't =
have to be. Depending on<br>characteristics of the original key =
you might need a more complex KDF<br>(e.g., a PBKDF if the original is a =
human-memorable password). This<br>(and various other details =
about accepted KDF technology that I'm<br>eliding) is the reason that =
you should want to think of a KDF rather<br>than a hash =
function.<br><br>Suppose some day you want to switch to a cipher with a =
different key<br>size. If all you have to do is tell the KDF how =
large the key is,<br>then it's easy, but if you have to change the KDF =
along with the<br>cipher then you have more work to do, work that might =
or might not be<br>easy. Being able to treat the protocol elements =
as modular has<br>significant advantages -and some pitfalls- over more =
monolythic<br>constructions.<br><br>Nico</blockquote></div></body></html>=
--Apple-Mail=_F896AE62-D666-44FC-8B86-9DEEB6331788--
--===============5710207578816997618==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5710207578816997618==--
