<p>I needed a constant-time AES round function for a project, and it wasn't much extra work, so I packaged the implementations I ported into a package that also serves as a <code>crypto/aes</code> replacement.</p>
<p>This also includes a constant-time GHASH, so using <code>crypto/cipher.NewGCM</code> will give you a constant-time implementation, even on systems without PCLMULQDQ or equivalent.</p>
<p>Caveats:</p>
<ul>
<li>All bugs are my fault, and not the fault of the implementation I ported.</li>
<li>The implementation exists to provide functionality for my pet project, so the gory details will continue to be exposed as sub-packages.</li>
<li>Performance is not great. The existing fallback code in the standard library is faster. If you don't care about timing attacks, don't use this package.</li>
<li>It should fallback to the runtime library when it is safe to do so (eg: on systems where <code>crypto/aes</code> will use AES-NI), but I haven't gotten around to that yet.</li>
<li>It could be faster with vector operations (eg: SSSE3).</li>
<li>It could be faster if the optimizer was better.</li>
<li>This does not make <code>crypto/tls</code> safe to use when timing attacks are a possibility.</li>
</ul>
<p><a href="https://git.schwanenlied.me/yawning/bsaes">https://git.schwanenlied.me/yawning/bsaes</a></p>
<hr/>**评论：**<br/><br/>php_questions: <pre><p>For everyone else that might need encryption that Is also in constant time, you should check out
<a href="https://godoc.org/golang.org/x/crypto/chacha20poly1305" rel="nofollow">https://godoc.org/golang.org/x/crypto/chacha20poly1305</a></p></pre>6e6ce582d8ac68a1e4e2: <pre><p>Indeed. That would also be faster than something like this, and harder for implementors to get wrong (by virtue of the primitives being easier to implement, correctly).</p></pre>epiris: <pre><p>This "bugs are my fault" AES implementation hosted on your personal .me domain DOES NOT serve as a drop in replacement for stdlib crypto/aes. How are you comfortable even suggesting that? I don't think your intent here is malice, my guess is your excited about the work you did here and just want to share? But it should probably be presented as such, with a clear indication it should not be used...</p></pre>6e6ce582d8ac68a1e4e2: <pre><blockquote>
<p>This "bugs are my fault" AES implementation hosted on your personal .me domain DOES NOT serve as a drop in replacement for stdlib crypto/aes.</p>
</blockquote>
<p>That's there because I don't want people complaining to the upstream for stuff that's likely porting errors.</p>
<blockquote>
<p>How are you comfortable even suggesting that?</p>
</blockquote>
<ul>
<li>I'm fairly comfortable with writing this sort of code in general.</li>
<li>Unless it produces wrong output (and it doesn't as far as I can tell), it's not going to be worse than <code>rijndael-alg-fst.c</code> converted to Go.</li>
<li>Other people seem to like the upstream code (<a href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/aes.c?rev=1.1&content-type=text/x-cvsweb-markup" rel="nofollow">http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/aes.c?rev=1.1&content-type=text/x-cvsweb-markup</a>).</li>
</ul>
<blockquote>
<p>But it should probably be presented as such, with a clear indication it should not be used...</p>
</blockquote>
<p>Anyone that wants a "secure" AES shouldn't be using <code>crypto/aes</code> either.</p></pre>chrj: <pre><blockquote>
<p>Anyone that wants a "secure" AES shouldn't be using crypto/aes either.</p>
</blockquote>
<p>Could you elaborate a bit on that part?</p></pre>6e6ce582d8ac68a1e4e2: <pre><p>Unless the system that the code is running on has hardware support for AES and there is assembly in <code>crypto/aes</code> for it, the runtime library's AES implementation uses table lookups for the S-box. This allows adversaries to do things like "recover the key via a cache timing attack", which is why, there is a warning in the standard library documentation (added in 1.8) about the implementation being vartime.</p>
<p>As far as I can tell, which implementation will get used isn't something that's query-able from the standard library at runtime. For the "fall back to <code>crypto/aes</code>" enhancement I planned, I was going to call <code>CPUID</code> on amd64 to check for AES-NI.</p>
<p>See also:</p>
<ul>
<li><a href="https://github.com/golang/go/issues/16821">https://github.com/golang/go/issues/16821</a></li>
<li><a href="https://cr.yp.to/antiforgery/cachetiming-20050414.pdf">https://cr.yp.to/antiforgery/cachetiming-20050414.pdf</a></li>
</ul>
<p>Edit: For a general overview on this topic, Peter Schwabe's slides from a lecture he gave on the topic is good as well (<a href="https://summerschool-croatia.cs.ru.nl/2016/slides/PeterSchwabe.pdf">https://summerschool-croatia.cs.ru.nl/2016/slides/PeterSchwabe.pdf</a>). An identical implementation to the generic <code>crypto/aes</code> one is features on page 13+ as the example on why this is a problem, and there are slides covering the bitslicing approach that the package I provide uses.</p></pre>epiris: <pre><p>Would love to see you create a example attack that operates within a main pkg operating on solely function calls. I doubt you will have much luck but would honestly be intrigued and impressed if you did. That said taking this beyond a theoretical best case scenario poc to a tangible attack vector towards any Go program isn't happening.</p></pre>6e6ce582d8ac68a1e4e2: <pre><p>It's been done against <code>rijndael-alg-fst.c</code> repeatedly, why do you think an identical algorithm in Go will be any different? If I were to do this I'd probably seek to replicate the attack presented in <a href="http://koclab.cs.ucsb.edu/docs/koc/c38.pdf">http://koclab.cs.ucsb.edu/docs/koc/c38.pdf</a> as it's not as finicky as say, the one described in djb's paper.</p></pre>epiris: <pre><p>Go has gc pauses, runtime scheduler that blocks, so many factors that would make a remote timing attack on real Go programs more difficult than the c equivalent. I really think this is academic / theoretical territory, but if you provide a example of a remote timing attack on amd64 implementation for example then I think you would have this fixed fairly quickly. </p>
<p>Point was if you don't provide any examples it's a bit difficult to accept all the measurable risk of your library when the core premise you wrote it on has no proven risk.</p></pre>6e6ce582d8ac68a1e4e2: <pre><p>So conditions similar to the Acıi ̧cmez, Schindler, Ko ̧c paper?</p>
<blockquote>
<p>Our experiments indicate that cache attacks can be used to extract
secret keys of remote systems if the system under attack runs on a server with a multitasking or multithreading system and a large enough workload.</p>
</blockquote>
<p>If anything, x86 or ARM would be more illustrative targets. <code>crypto/aes</code> is fine on some but not all amd64 systems, and I've said as much.</p>
<p>The code is a result of needing an AES round function to implement AEZ, looking at the one included in the runtime library and "reacting to a constantly changing threat landscape", from 10 years ago.</p></pre>epiris: <pre><p>You're missing the entire point still. As it stands no measurable risk to the AES implementation exists in Go, until you or someone else provides an attack vector to back your assertion. Once a vector is known we can begin to quantify the risk for the average Go user. Is TLS affected? Is net/https? What resources are needed to execute the attack? Once presented with new information I may or may not form a new conclusion that your library is less risk than the stdlib.</p>
<p>As it stands now the stdlib AES implementation is well reviewed and tested on the Go builders, delivered through secure channels with accountability and auditing, on and on. Every positive of the stdlib is currently a quantifiable risk with your implementation. I've never met someone in the security space who would be okay advocating usage of a freshly rolled AES library against something as vetted as the std lib. I still don't understand how someone so passionate about security, involved with TOR, etc, is okay with it. Regardless I've exhausted the topic and my points several posts ago, I have been trying to pry for additional interesting technical content mostly because your confidence in your implementation made me curious. But until something concrete is delivered I'm not willing to concede here. Happy coding friend.</p></pre>tcrypt: <pre><p>You're missing the point. Security is about layering and secure defaults. Just because the Go GC has pauses and there are other blockers, does not mean you should abandon well-known and well-tested principles. If it turns out those are predictable or open to manipulation they're no longer saving you.</p>
<p>You're correct that you shouldn't trust some random and untested package, but that doesn't mean the existing package has satisfactory security for all applications.</p></pre>epiris: <pre><p>You may be a fantastic developer who has produced a correct aes implementation. I don't question your comfort in writing this code, because your comfort is not important. What is important is rigorous peer review, secure and trusted distribution through accountability, auditing and monitoring, commitment to maintaining and reacting to a constantly changing threat landscape, on and on.</p>
<p>I didn't mention your code or click your repo, because it's not important. It's not worth looking at while every other factor from a secure aes implementation is missing. The comment about the Go aes package.. which has every factor I listed here is just a hint to avoid this and im fairly certain most cryptologists or experienced engineers would agree.</p>
<p>Point is, even the most esteemed cryptologists with vast academic references are not comfortable omitting peer review. So I am still left unsure how you are, but I don't need to be, I did my due diligence by raising the points for other engineers.</p></pre>6e6ce582d8ac68a1e4e2: <pre><blockquote>
<p>The comment about the Go aes package.. which has every factor I listed here is just a hint to avoid this and im fairly certain most cryptologists or experienced engineers would agree.</p>
</blockquote>
<p>A comment on the standard Go aes package, that is a port of <em>the</em> implementation responsible for a multitude of "AES is vulnerable to cache timing attack" papers, dating back over a decade, hardware acceleration, and that has a warning in the documentation about how it is not constant-time.</p>
<p>If it makes you feel better, I could provision a git.torproject.org repository for it, because I was planning on using it for stuff there.</p></pre>epiris: <pre><p>The comment is about not being constant time, you are again avoiding my primary concerns of peer review and everything else accompanying a cryptographic software by focusing on the implementation.</p>
<p>You may be a great engineer, cryptologist, etc. Again that is not the point I wanted to raise, from the beginning. The original concern stands: how are you comfortable suggesting using of a implementation of aes that has not undergone peer review? This is nothing personal, remember I don't know you. Your name is all hex characters with a .me sub domain and you post a lib as a drop in replacement for the standard library.. is my position really unreasonable? :-)</p>
<p>Torproject is great, are you affiliated with them? If you are is it typical for cryptography algorithms to be implemented by maintainers and contributors of TOR without peer review? Ones with the same sort of dependency graphs of stdlib. I'm genuinely curious, perhaps my ways of thinking are dated and I'm not rugged enough. Regardless have a good evening.</p></pre>6e6ce582d8ac68a1e4e2: <pre><blockquote>
<p>is my position really unreasonable? :-)</p>
</blockquote>
<p>Not entirely. I would be deeply concerned if people didn't look at the code before using it. Ultimately, it's up to people to either use it or not. My stance on such things is that I examine library code that I use by default. Sorry if that assumption carried over.</p>
<p>Orthogonal to if people should use my package or not. I still stand by my assertion that, <code>src/crypto/aes/block.go</code> from the runtime library is fatally broken for anyone that cares about timing attacks. It has been reviewed, it has failed it's review years ago. If trusted library code is a big deal to them, then perhaps they should call into one of the well established C libraries.</p>
<blockquote>
<p>Torproject is great, are you affiliated with them? </p>
</blockquote>
<p>It'd be kind of hard to get a repo there otherwise won't it?</p>
<blockquote>
<p>If you are is it typical for cryptography algorithms to be implemented by maintainers and contributors of TOR without peer review?</p>
</blockquote>
<p>I do part of the review for changes to stuff there. So yeah there's review. The amount depends on the project/component.</p>
<blockquote>
<p>Regardless have a good evening.</p>
</blockquote>
<p>You too.</p></pre>epiris: <pre><p>My question on TOR was to hint at revealing your role, if you are a phd'd cryptologist it changes the context yea? If you sysadmin yum repos probably not. Neither changes the importance of peer review for a core crypto primitive. Did members of the TOR project review this implementation, if so which ones?</p></pre>Creshal: <pre><p>Is libsodium's AES implementation not constant-time?</p></pre>6e6ce582d8ac68a1e4e2: <pre><p>It is. It's a C version of Käsper/Schwabe's SSSE3 bitsliced code.</p>
<p><a href="https://github.com/jedisct1/libsodium/tree/master/src/libsodium/crypto_stream/aes128ctr/nacl">https://github.com/jedisct1/libsodium/tree/master/src/libsodium/crypto_stream/aes128ctr/nacl</a></p>
<p><code>cgo</code> and concurrency don't mix so calling external libraries isn't really an option for me, and the BearSSL code was easier to do in Go.</p></pre>
