<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libcrypto/evp, branch OPENBSD_7_9</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2026-01-30T13:57:13+00:00</updated>
<entry>
<title>EVP_SealInit(): clear random key on exit</title>
<updated>2026-01-30T13:57:13+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2026-01-30T13:57:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=06d332fd67117492593691579e28332dffe3eb74'/>
<id>urn:sha1:06d332fd67117492593691579e28332dffe3eb74</id>
<content type='text'>
ok jsing kenjiro
</content>
</entry>
<entry>
<title>EVP_{Open,Seal}Init(): remove redundant EVP_CIPHER_CTX_reset() calls</title>
<updated>2026-01-30T13:54:28+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2026-01-30T13:54:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=fdcc97e7af1a70232b9b2e46ae9336350095d9b1'/>
<id>urn:sha1:fdcc97e7af1a70232b9b2e46ae9336350095d9b1</id>
<content type='text'>
The subsequent EVP_{Decrypt,Encrypt}Init_ex() calls already do that.

pointed out by jsing
</content>
</entry>
<entry>
<title>EVP_SealInit(): minor cleanup.</title>
<updated>2026-01-30T13:51:44+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2026-01-30T13:51:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=9e1ab34f681a4aaf84ec91a6d2b36c59c85b73d7'/>
<id>urn:sha1:9e1ab34f681a4aaf84ec91a6d2b36c59c85b73d7</id>
<content type='text'>
Explicitly compare pointers against NULL, turn the function into single
exit, add hint at why npubk &lt;= 0 or pubk == NULL are a success path:

The documentation briefly explains that EVP_OpenInit() and EVP_SealInit()
is able to initialize the EVP_CIPHER_CTX in two steps exactly like the
EVP_CipherInit_ex() API they wrap: the first call with non-NULL cipher
(aka type) only sets the cipher on the ctx, then it returns to allow
callers to customize the EVP_CIPHER_CTX, and a second call with
cipher == NULL skips the initialization and finishes the ctx setup
by setting key and iv.

Prompted by a report by Niels Dossche.

ok jsing kenjiro
</content>
</entry>
<entry>
<title>EVP_SealInit: do not return -1 on error</title>
<updated>2026-01-30T13:47:22+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2026-01-30T13:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=d08c52f7b1df87a6d0b5aa0f42fdeee3f3c0e6b9'/>
<id>urn:sha1:d08c52f7b1df87a6d0b5aa0f42fdeee3f3c0e6b9</id>
<content type='text'>
It is documented that EVP_SealInit() returns 0 on error. So -1 is wrong.

Reported by Niels Dossche

ok jsing kenjiro
</content>
</entry>
<entry>
<title>EVP_OpenInit(): minor cleanup</title>
<updated>2026-01-30T13:42:46+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2026-01-30T13:42:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=941f37f21fb644009376b73f2065913887fa1bd0'/>
<id>urn:sha1:941f37f21fb644009376b73f2065913887fa1bd0</id>
<content type='text'>
Explicitly compare pointers against NULL, turn the function into single
exit and explain why priv == NULL is a success (hint: muppet API).

Prompted by a report by Niels Dossche.

ok jsing kenjiro
</content>
</entry>
<entry>
<title>Remove unused function pointer from struct aead_aes_gcm_ctx.</title>
<updated>2025-07-22T09:31:09+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2025-07-22T09:31:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=ccfa2eb65bcf08f9a43232aa86ef9db63b417902'/>
<id>urn:sha1:ccfa2eb65bcf08f9a43232aa86ef9db63b417902</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Remove remaining block128_f casts from EVP AES.</title>
<updated>2025-07-22T09:29:31+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2025-07-22T09:29:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=bac3e025d0e76adcdafc8b26a67bf5a0a4abbed6'/>
<id>urn:sha1:bac3e025d0e76adcdafc8b26a67bf5a0a4abbed6</id>
<content type='text'>
Use aes_encrypt_block128() instead of AES_encrypt(), avoiding risky casts.
</content>
</entry>
<entry>
<title>Move AES-NI for ECB out of EVP.</title>
<updated>2025-07-22T09:13:49+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2025-07-22T09:13:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=da7a63b669ad2a502ae120afede3fd850082e8b6'/>
<id>urn:sha1:da7a63b669ad2a502ae120afede3fd850082e8b6</id>
<content type='text'>
Make aes_ecb_encrypt_internal() replaceable and provide machine dependent
versions for amd64 and i386, which dispatch to AES-NI if appropriate.
Remove the AES-NI specific EVP methods for ECB.

This removes the last of the machine dependent code from EVP AES.

ok bcook@ joshua@ tb@
</content>
</entry>
<entry>
<title>Move AES-NI from EVP to AES for CCM mode.</title>
<updated>2025-07-21T10:24:23+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2025-07-21T10:24:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=b73facdeca098be7e538e556c1a293942db3110c'/>
<id>urn:sha1:b73facdeca098be7e538e556c1a293942db3110c</id>
<content type='text'>
The mode implementation for CCM has two variants - one takes the block
function, while the other takes a "ccm64" function. The latter is expected
to handle the lower 64 bits of the IV/counter but only for 16 byte blocks.
The AES-NI implementation for CCM currently uses the second variant.

Provide aes_ccm64_encrypt_internal() as a function that can be replaced on
a machine dependent basis, along with an aes_ccm64_encrypt_generic()
function that provides the default implementation and can be used as a
fallback. Wire up the AES-NI version for amd64 and i386, change EVP's
aes_ccm_cipher() to use CRYPTO_ctr128_{en,de}crypt_ccm64() with
aes_ccm64_encrypt_internal()) and remove the various AES-NI specific
EVP_CIPHER methods for CCM.

ok tb@
</content>
</entry>
<entry>
<title>Simplify AES-XTS implementation and remove AES-NI specific code from EVP.</title>
<updated>2025-07-13T06:01:33+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2025-07-13T06:01:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=f0234f5a33ecf3b2784f3e73bdf1e937abe56599'/>
<id>urn:sha1:f0234f5a33ecf3b2784f3e73bdf1e937abe56599</id>
<content type='text'>
Provide aes_xts_encrypt_internal() and call that from aes_xts_cipher().
Have amd64 and i386 provide their own versions that dispatch to
aesni_xts_encrypt()/aesni_xts_decrypt() as appropriate. The
AESNI_CAPABLE code and methods can then be removed.

ok tb@
</content>
</entry>
</feed>
