aboutsummaryrefslogtreecommitdiffstats
path: root/src/engine/aes_isa_eng
Commit message (Collapse)AuthorAgeFilesLines
* Don't hide funcions in engine subclasses that are public in baselloyd2010-06-161-1/+1
|
* More Doxygen updates/fixeslloyd2010-06-151-0/+4
|
* Use "/*" instead of "/**" in starting comments at the begining of a file.lloyd2010-06-071-1/+1
| | | | | This caused Doxygen to think this was markup meant for it, which really caused some clutter in the namespace page.
* Remove stubs for VIA Padlock support. I have no plans to implement itlloyd2010-01-051-17/+0
| | | | | | and don't even have access to a VIA with AES so could not test it anyway. If someone else wants to do it, then the implementation for AES-NI should provide a good template.
* Fix compile; aes engine header is internallloyd2010-01-041-1/+2
|
* Add missing BOTAN_DLL exports.lloyd2009-12-162-1/+9
| | | | Move most of the engine headers to internal
* Add AES-192 using AES-NI. Tested OK with Intel's simulator.lloyd2009-11-101-2/+0
| | | | | | | Currently requires SSE4.1 for _mm_extract_epi32 for the key schedule, it would be nice to remove this dependency, though all currently known/scheduled chips with AES-NI (Intel Westmere and Sandy Bridge, and AMD Bulldozer) are supposed to include SSE 4.1 so this is not a huge problem.
* Rename CPUID::has_intel_aes to has_aes_intel, and add CPUID::has_aes_via,lloyd2009-11-101-2/+2
| | | | which is currently just a stub returning false.
* Fix errors in the AES-256 key schedule for the AES-NI version. Now passeslloyd2009-11-101-1/+1
| | | | | | | | | tests under Intel's emulator. Document and enable in the engine. Merge both versions to aes_intel.cpp - some shared code and much similiar structure which might be sharable via macros.
* Add a new need_isa marker for info.txt that lets a module dependlloyd2009-11-061-5/+5
| | | | | | | | | | | | on a particular ISA extension rather than a list of CPUs. Much easier to edit and audit, too. Add markers on the AES-NI code and SHA-1/SSE2. Serpent and XTEA don't need it because they are generic and only depend on simd_32 which will silenty swap out a scalar version if SSE2/AltiVec isn't enabled (since it turns out on supersclar processors just doing 4 blocks in parallel can be a win even in GPRs). Add pentium3 to the list of CPUs with rdtsc, was missing. Odd!
* Add a complete but untested AES-128 using the AES-NI intrinsics.lloyd2009-11-061-10/+8
| | | | | | | | | | | | | | | | | | From looking at how key gen works in particular, it seems easiest to provide only AES-128, AES-192, and AES-256 and not a general AES class that can accept any key length. This also has the bonus of allowing full loop unrolling which may be a win (how much so will depend on the latency/throughput of the AES instructions which is currently unknown). No block interleaving, though of course it works very nicely here, simply due to the desire to keep things simple until what is currently here can actually be tested. (Intel has an emulator that is supposed to work but just crashes on my machine...) I'm not entirely sure if byte swapping is required. Intel has a white paper out that suggests it isn't (and really it would have been stupid of them to not build this into the aes instructions), but who knows. If it turns out to be necessary there is a pretty fast bswap instruction for SSE anyway.
* Stub for AES class using Intel's AES-NI instructions and an engine forlloyd2009-11-063-0/+85
providing it. Also stubs in the engine for VIA's AES instructions, but needs CPUID checking also.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 19:35:02 +0000