A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2025-06-08T22:40:31+00:00 2025-06-08T22:40:31+00:00 schwarze 2025-06-08T22:40:31+00:00 urn:sha1:8be86af02fed1bda350c8dd14ee064cb66e3b0f5 2024-12-20T01:54:03+00:00 schwarze 2024-12-20T01:54:03+00:00 urn:sha1:258718f3cccab5f78525ddaca79ad85bdc4840da algorithm-independent EVP_EncryptInit(3) manual as another step in making the latter leaner and more palatable. As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide a better fighting chance to programmers who see themselves forced to support CCM for whatever reason. It documents the mandatory, but so far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the description of the three EVP_CTRL_CCM_SET_* control commands and the numerous related quirks more precise. 2024-12-17T18:11:44+00:00 schwarze 2024-12-17T18:11:44+00:00 urn:sha1:b61fd72fb49402139f31d4e60126555d520b2f9d The main benefit is moving the cumbersome and error-prone method of using EVP_EncryptInit(3) for AES-GCM out of the important, but obese manual page EVP_EncryptInit(3), and to create a logical place for pointing readers to the safer and more flexible EVP_AEAD_CTX_init(3). As a side benefit, document three control commands that were so far undocumented and make the description of three others more precise. Feedback and OK tb@. 2024-12-08T17:41:23+00:00 schwarze 2024-12-08T17:41:23+00:00 urn:sha1:ee3d1c0f143450b3ef7e6244b9b1b99567a19486 and document them properly in their own manual page, including the control commands EVP_CTRL_SET_RC2_KEY_BITS and EVP_CTRL_GET_RC2_KEY_BITS that were so far undocumented. Arguably, the main benefit is another small step making the important, but still obese EVP_EncryptInit(3) manual page more palatable. 2024-11-09T22:03:49+00:00 schwarze 2024-11-09T22:03:49+00:00 urn:sha1:4ac149745dc802177e5fbc4700d5074a1e28baf7 This is relevant because EVP_EncryptInit(3) takes a "key" argument, and users need to consider the size of that argument. While here, also mention whether ciphers are stream ciphers or block ciphers and what the block size is. 2024-07-21T08:36:43+00:00 tb 2024-07-21T08:36:43+00:00 urn:sha1:28352aaf8b4f3dbd154f1c25e1555c80716bb293 This uses the same language in most manuals mentioning the obsolete ENGINE parameters. Make it clear that it is always ignored and that NULL should be passed. Always call it engine instead of a mix of e pe, impl, eng. 2023-12-26T22:13:00+00:00 schwarze 2023-12-26T22:13:00+00:00 urn:sha1:4f58ce589879d16fdd05a6ac7df7d69a5b978412 in particular s/inl/in_len/ and s/outl/out_len/ as suggested by tb@. While here, also get rid of the "outm" placeholder that has been around since the file was added to OpenSSL in 2000, replacing it with the usual "out" in the four function prototypes affected; tb@ and myself suspect it was simply a typo followed by copy and paste. Slightly improve variable naming in the examples, too, for clarity and consistency, even though that doesn't turn the examples into good examples. OK tb@ 2023-12-01T13:43:37+00:00 schwarze 2023-12-01T13:43:37+00:00 urn:sha1:274200c32ee320eb0f58a1c3d53265bbbdd12292 Remove some lies and some irrelevant historical information about the non_ex variants and waste fewer words deprecating them. Telling people to type longer function names and to pass an ignored NULL argument doesn't really help anything. Also talk less about those ignored ENGINE arguments. OK tb@ 2023-12-01T10:40:21+00:00 schwarze 2023-12-01T10:40:21+00:00 urn:sha1:4d0afa658da0dc721072f305e806d225dad77c22 but it is still excessively long and complicated. To reduce the amount of distractions a bit, split out three deprecated functions into a new manual page EVP_CIPHER_CTX_init(3). No text change. In part suggested by tb@, who agrees with the direction. 2023-08-31T17:27:41+00:00 schwarze 2023-08-31T17:27:41+00:00 urn:sha1:718a51ea125c68db5409e266fe178f9ad937b59c and EVP_CIPHER_CTX_set_flags(3) out of the excessively large and unwieldy EVP_EncryptInit(3). This causes a number of inaccuracies and gaps to stand out, but i'm not mixing text changes or content additions into this split. Using very useful feedback from tb@ regarding what belongs together and how important the various functions are. I refrained from bothering him with the complete patch, but he likes the general direction.