<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in aes-xts.h</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>d47db9bf50d28647689e6743ee93c45cb755ffc3 - Merge tag &apos;libcrypto-updates-for-linus&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux</title>
        <link>http://kernelsources.org:8080/source/history/linux/include/crypto/aes-xts.h#d47db9bf50d28647689e6743ee93c45cb755ffc3</link>
        <description>Merge tag &apos;libcrypto-updates-for-linus&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linuxPull crypto library updates from Eric Biggers: &quot;Add library APIs for most AES encryption modes that are used in the  kernel (ECB, CBC, CBC-CTS, CTR, XCTR, XTS, GCM, CCM).  These AES modes have many in-kernel users that are currently using the  crypto_skcipher or crypto_aead APIs. These existing APIs are difficult  to use and inefficient. Until now, the lack of proper library support  for these has been the main gap in the crypto library.  This set of changes is the next stage of addressing it:   - Implement the new APIs on top of the existing support for     single-block AES in the library.   - Fully document the new APIs.   - Migrate the only user of the old AES-GCM library API to the new,     more flexible API; then remove the old API and its implementation.   - Wire up the new APIs to the traditional crypto API by adding     crypto_skcipher and crypto_aead algorithms.     This makes the new APIs be covered by the traditional crypto API&apos;s     self-tests. It also makes them be already used for real on systems     that don&apos;t have architecture-optimized code for these modes.     But most importantly, this is a prerequisite for migrating the     architecture-optimized code for these AES modes (i.e.     arch/*/crypto/aes*) into the library, which as usual will eliminate     a lot of redundant &quot;glue&quot; code.  Note that unlike some of the other algorithms that have been migrated  to the library, e.g. SHA-512, for these AES modes there was too much  to get done in one cycle. Nor did it make sense to handle these modes  one at a time, because they tend to be coupled together or depend on  each other, especially in the architecture-optimized AES code.  Thus, most of the benefits (reductions in lines of code, performance  improvements, etc.) will follow in later cycles when  architecture-optimized code is migrated into the library and users of  crypto_skcipher and crypto_aead are updated to use the new APIs.  The design of the new APIs was informed by writing proof-of-concept  patches for many kernel subsystems currently accessing these same  algorithms via crypto_skcipher or crypto_aead (patches 18-33 of  https://lore.kernel.org/r/20260707053503.209874-1-ebiggers@kernel.org/).  While those patches will be resent for real later, the total diffstat  for them was negative 1905 lines. So clearly the new APIs are quite a  bit easier to use and align better with what users actually need.  Besides the new AES encryption APIs, there are also a few changes for  improved AES-CMAC key and context zeroization&quot;* tag &apos;libcrypto-updates-for-linus&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:  mac80211: fils_aead: Use __cleanup() instead of memzero_explicit()  Bluetooth: SMP: clear the aes_cmac_key when done  smb: clear the aes_cmac_key and aes_cmac_ctx when done  lib/crypto: aes-cmac: Add zeroization functions  lib/crypto: aesgcm: Remove old AES-GCM library  x86/sev: Remove obsolete virtual address check  x86/sev: Use new AES-GCM library  crypto: aes - Add CCM support using library  crypto: aes - Add GCM support using library  crypto: aes - Add XTS support using library  crypto: aes - Add CTR and XCTR support using library  crypto: aes - Add CBC and CBC-CTS support using library  crypto: aes - Add ECB support using library  lib/crypto: aes: Add CCM support  lib/crypto: aes: Add GCM support  lib/crypto: aes: Add XTS support  lib/crypto: aes: Add CTR and XCTR support  lib/crypto: aes: Add CBC and CBC-CTS support  lib/crypto: aes: Add ECB support  crypto: xts - Split out __xts_verify_key() helper

            List of files:
            /linux/include/crypto/aes-xts.h</description>
        <pubDate>Tue, 18 Aug 2026 04:16:42 +0200</pubDate>
        <dc:creator>Linus Torvalds &lt;torvalds@linux-foundation.org&gt;</dc:creator>
    </item>
<item>
        <title>de9cccc5fd196e364536da4f5a7af18c66c7b31f - lib/crypto: aes: Add XTS support</title>
        <link>http://kernelsources.org:8080/source/history/linux/include/crypto/aes-xts.h#de9cccc5fd196e364536da4f5a7af18c66c7b31f</link>
        <description>lib/crypto: aes: Add XTS supportAdd support for AES-XTS to the crypto library.This will be used to provide a streamlined implementation of the&quot;xts(aes)&quot; crypto_skcipher algorithm.  I&apos;m also planning to use thisdirectly in fscrypt and blk-crypto-fallback.As usual, the architecture-optimized AES-XTS code will be migrated intothe library as well (using the hooks provided in this commit),eliminating lots of repetitive boilerplate code.  Compared to directimplementation of &quot;xts(aes)&quot;, I&apos;ve also eliminated the requirement forarchitectures to implement ciphertext stealing, as the library justhandles it portably instead.  That will simplify things considerably.Initial test coverage is provided by the crypto_skcipher support addedin a later commit.  I&apos;m planning a KUnit test suite as well.Link: https://patch.msgid.link/20260715221153.246410-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;

            List of files:
            /linux/include/crypto/aes-xts.h</description>
        <pubDate>Thu, 16 Jul 2026 00:11:45 +0200</pubDate>
        <dc:creator>Eric Biggers &lt;ebiggers@kernel.org&gt;</dc:creator>
    </item>
</channel>
</rss>
