<p dir="ltr"><br>
On 7 Nov 2015 02:25, "Will Sargent" <<a href="mailto:will.sargent@gmail.com">will.sargent@gmail.com</a>> wrote:<br>
><br>
> On Fri, Nov 6, 2015 at 6:01 AM, Max Kington <<a href="mailto:mkington@webhanger.com">mkington@webhanger.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Wed, Nov 4, 2015 at 7:09 PM, Will Sargent <<a href="mailto:will.sargent@gmail.com">will.sargent@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi there,<br>
>>><br>
>>> I'm looking at a very specific issue, where the same secret key is used with AES-CTR for encryption, and then later that same key is used for signing the ciphertext with HMAC-SHA1.  I know that generally it's unsafe for CBC-MAC (which I'm not familiar with) and RSA keys: I want to be able to say AES / HMAC is a safe or unsafe construction, and so far I'm not sure which. <br>
>><br>
>><br>
>> Ultimately you could only be sure it's an unsafe construction but only have some confidence in it being a safe construction.  <br>
>><br>
>> I guess the real question is to what end?  <br>
>><br>
>> As Ian says, are you reviewing an existing system?  If so are you trying to assert that the application *needs* changing to better apply a separation of use principle for the purpose of a key (namely that your encryption and integrity keys should be different for all the key management reasons that's a good idea)?  Or is is that you want to assert that in this case, the risk is low and doesn't *have* to be changed but could be? <br>
><br>
><br>
> This is a system I'm decommissioning, because homegrown crypto is a Bad Idea.  I want to be able to assert that the reuse of keys here, while not recommended, has not been actively broken (or at least, there are no publications to that effect), and if they used AES-CTR and then immediately MACed the result and didn't mix it with anything... then they're probably fine.  Maybe.</p>
<p dir="ltr">I wouldn't have said homegrown use of crypto was necessarily a bad idea (tm). In fact I'd go soc far as to say that we should be careful to not make that an unqualified statement and say what we consider the risk there. What we usually worried about is home spun algorithms (with poor properties) and poor constructions of known ones. Assembling the tools in the toolbox is in my book fine if you know what you're doing.<br>
><br>
>> I think you need to be a bit careful about what is meant here by safe and unsafe and think about it in the context of what you're concerned about.  Specific cryptographic attacks relating to using AES as the chosen block cipher to underpin MAC OR the general principal of key separation. <br>
><br>
><br>
> Right -- I know that AES-CTR + HMAC is a construction and so there are Ways To Do That Wrong.  However, I can't know how users put them together.  I have a library that exposes an encrypt method, and a sign (HMAC-SHA1) method -- no real way to know how users composed them, if they did at all.  </p>
<p dir="ltr">I think on that basis you can't necessarily say this is bad. </p>
<p dir="ltr">><br>
>>  Key purpose reuse is what Weis goes on to talk about is the general idea that every time you use a key you expose information about the key.  If you are ever forced to have to change a key because it has been compromised (either stolen or broken and recovered) then you are able to make assertions about what you've lost, i.e. the data previously might not have had integrity but it wasn't ever exposed.  Can I go back, check the contents of my data and be satisfied that it is what was transmitted and not interfered with but still be happy it's not been leaked.  <br>
>><br>
>> The general perspective case to my mind probably doesn't warrant changing an incumbent system (at least in any high priority) but would make me want to encourage a change to the design of a system yet to be deployed if that's an option.<br>
>><br>
>> Sorry if this is all a bit teaching granny to suck eggs but are you worried about the general case or some specific attack? Because that matters a lot in the context of your question.<br>
><br>
><br>
> It's more general advice.  The encrypt method is not used at all within the system itself, only signing is used.  Some end users found and started using the encrypt / sign methods for their own crypto and so I'm deprecating those methods and sticking large warnings over everything.  Then I'm going to point them at Kalium or Keyczar and wish them good luck.</p>
<p dir="ltr">If that's the case and that seems fair enough they still need to use the pieces sensibly and using certainly NaCl still means you can shoot yourself in the foot.  Keyczar I guess less so.</p>
<p dir="ltr">BUT!</p>
<p dir="ltr">Two things, in my world cryptographic libraries need creating as special kinds of assets so that if they later found to be flawed we can find them. This may not be a worry for you but consider if you're introducing more complexity which you don't need.</p>
<p dir="ltr">Change it when you need to which I guess you're kind of doing. </p>
<p dir="ltr">Secondly if people are going to do a rethink and think more broadly about key management then that's a deeper bit of reengineering and if the opportunity presents itself that might be a better (or additional) legacy to your review.</p>
<p dir="ltr">Are you decommissioning it in whole *because* of the crypto? Or just these libraries all be the quality of their use by the parent app is unknown? I didn't quite follow that.<br></p>
<p dir="ltr">Cheers<br>
M</p>