<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">This is a system I'm decommissioning, because homegrown crypto is a Bad<br>
Idea.<br>
</span></blockquote> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's quite controversial.</blockquote><div><br></div><div>Well, the first version used AES-ECB with unbounded input.  The second version used AES-CTR without a MAC, and has a versioning scheme so it can fall back to AES-ECB.  It's not something that needs to be around, and it comes with no instruction manual.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Right -- I know that AES-CTR + HMAC is a construction and so there are<br>
Ways To Do That Wrong.  However, I can't know how users put them<br>
together.  I have a library that exposes an encrypt method, and a sign<br>
(HMAC-SHA1) method -- no real way to know how users composed them, if<br>
they did at all.<br>
</blockquote>
<br>
<br></span>
Ah.  So maybe what you really want is a library that exposes an encrypt&auth method.  This is called Authenticated Encryption or AEAD, and is a thing.  It's not so well standardised as yet, there is an active competition to provide it.  Probably the algorithm that is most popular in this vein is Chacha/Poly but even that is two algorithms composed.<br></blockquote><div><br></div><div>I poked at this a bit with an AES-GCM proof of concept: <a href="https://github.com/wsargent/jce-aes-cipher-poc">https://github.com/wsargent/jce-aes-cipher-poc</a> but ultimately, it's better handled by a high level crypto library. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
(BTW, calling the HMAC-SHA1 'signing' isn't quite right.  Signing is reserved for public key ops, as they have long term reliability, whereas the use of HMACs is considered to be ephemeral, temporary, good enough to stop an attacker in the next minute.  Authentication is the verb most used there.)</blockquote><div><br></div><div>Yeah, that vocab comes from Keyczar, which uses a "Signer" for both RSA signatures and HMAC: </div><div><br></div><div><a href="https://github.com/google/keyczar/wiki/HmacKey">https://github.com/google/keyczar/wiki/HmacKey</a></div><div><a href="https://github.com/google/keyczar/wiki/OperationSign">https://github.com/google/keyczar/wiki/OperationSign</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It's more general advice.  The encrypt method is not used at all within<br>
the system itself, only signing is used.  Some end users found and<br>
started using the encrypt / sign methods for their own crypto and so I'm<br>
deprecating those methods and sticking large warnings over everything.<br>
</blockquote>
<br></span>
Hmmm... you haven't established a harm as yet.  Maybe you know something else, but it doesn't seem like a huge problem that they're putting some extra encryption in place?</blockquote><div><br></div><div>I don't see that there's an established harm or vulnerability, but it's not something we want to maintain.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Then I'm going to point them at Kalium or Keyczar and wish them good luck.<br>
</blockquote>
<br>
<br></span>
If you're moving them from an old deprecated library to a newer supported one, ok.  OTOH, if you're moving them from some standard inhouse thing that they already have, and are just adding another external dependency, well, that could cause issues on its own.</blockquote><div><br></div><div>Right -- there is no "newer supported" one, and the current one has never been supported, it was discovered.  It may cause some issues, but long term moving to a supported library is the right move.</div><div><br></div><div>Will. <br></div></div></div></div>