<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 7:09 PM, Will Sargent <span dir="ltr"><<a href="mailto:will.sargent@gmail.com" target="_blank">will.sargent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi there,<div><br></div><div>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. </div></div></blockquote><div><br></div><div>Ultimately you could only be <i>sure </i>it's an unsafe construction but only have some confidence in it being a safe construction.  </div><div><br></div><div>I guess the real question is to what end?  </div><div><br></div><div>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? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>I've got two different sources, one saying that this is safe, the other one that it is not.</div><div><br></div><div>Steve Weis here says that AES is not safe when using the same key for both signing and encryption:</div><div><br></div><div><a href="https://youtu.be/KDvt_0cafPw?t=36m45s" target="_blank">https://youtu.be/KDvt_0cafPw?t=36m45s</a></div></div></div></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div></div><div><br></div><div>But Thomas Porrin says:</div><div><br></div><div>"<span style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:15px;line-height:15.6px">With HMAC vs AES, no such interference is known. The </span><em style="margin:0px;padding:0px;border:0px;font-size:15px;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;line-height:15.6px">general feeling</em><span style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:15px;line-height:15.6px"> 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."</span></div><div><br></div><div><a href="http://crypto.stackexchange.com/a/8086/10979" target="_blank">http://crypto.stackexchange.com/a/8086/10979</a><br></div><div><br></div><div>I've looked online, but don't know exactly what phrases to look for -- "key reuse" is typically used in a "reusing key with same IV" sense, and "key type mixing" doesn't show very much either.  "key separation principle" brings up "On the Importance of the Key Separation Principle for Different Modes of Operation" which is firewalled, and a paper on Key Reuse:</div><div><br></div><div>* <a href="https://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf" target="_blank">https://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf</a></div></div></blockquote><div><br></div><div> 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.  </div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>