<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libcrypto/aes, branch libressl-v3.3.5</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=libressl-v3.3.5</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=libressl-v3.3.5'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2018-11-07T18:31:16+00:00</updated>
<entry>
<title>Use memmove() instead of memcpy() to get rid of the need for</title>
<updated>2018-11-07T18:31:16+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2018-11-07T18:31:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=1ccfdc4633eea23918743a87973b287510d77c28'/>
<id>urn:sha1:1ccfdc4633eea23918743a87973b287510d77c28</id>
<content type='text'>
non-overlapping *in and *out buffers as we're already implementing
the "in place (un)wrapping" algorithms as given in RFC 3394.  This
removes a gratuitous API difference to OpenSSLin these undocumented
functions. Found while working on wycheproof regress tests.

ok beck jsing
</content>
</entry>
<entry>
<title>RFC 3394 section 2 states that we need at least two 64 bit blocks</title>
<updated>2018-10-20T15:53:09+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2018-10-20T15:53:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=030940374172037385e4db118b4bec57b798f314'/>
<id>urn:sha1:030940374172037385e4db118b4bec57b798f314</id>
<content type='text'>
for wrapping and, accordingly, three 64 bit blocks for unwrapping.
That is: we need at least 16 bytes for wrapping and 24 bytes for
unwrapping.  This also matches the lower bounds that OpenSSL have
in their CRYPTO_128_{un,}wrap() functions.

In fact, if we pass an input with 'inlen &lt; 8' to AES_unwrap_key(),
this results in a segfault since then inlen -= 8 underflows.

Found while playing with the Wycheproof keywrap test vectors.

ok bcook
</content>
</entry>
<entry>
<title>KNF: move two opening curly braces of function bodies to their own lines</title>
<updated>2018-04-03T21:59:37+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2018-04-03T21:59:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=426a421e14686f45bc9d7f73c4ea02bac4262e4d'/>
<id>urn:sha1:426a421e14686f45bc9d7f73c4ea02bac4262e4d</id>
<content type='text'>
</content>
</entry>
<entry>
<title>On OpenBSD/armv7 we deliberately trap unaligned access.  Unfortunately</title>
<updated>2018-01-07T12:35:52+00:00</updated>
<author>
<name>kettenis</name>
<email></email>
</author>
<published>2018-01-07T12:35:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=849b82a11d72ca02a63517d93855de2ddddff11b'/>
<id>urn:sha1:849b82a11d72ca02a63517d93855de2ddddff11b</id>
<content type='text'>
the assembly code in libcrypto assumes unaligned access is allowed for
ARMv7.  Make these paths conditional on __STRICT_ALIGNMENT not being
defined and define __STRICT_ALIGNMENT in arm_arch.h for OpenBSD.

ok tom@
</content>
</entry>
<entry>
<title>http://repzret.org/p/repzret/</title>
<updated>2017-12-11T05:48:01+00:00</updated>
<author>
<name>deraadt</name>
<email></email>
</author>
<published>2017-12-11T05:48:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=06a79a412573b1755b84374f8fdb1970ca59f1b6'/>
<id>urn:sha1:06a79a412573b1755b84374f8fdb1970ca59f1b6</id>
<content type='text'>
My read of this:  Long time ago (Think Conan, not dinasaurs) during the race
to make speedier processors, a cpu vendor built a pipeline with a bad stall,
and proposed a tremendously hasky workaround.  A wizard adopted this into his
perl scroll, and failed to reflect later when no compiler adopted the practice.
This relic remains at the tail end of some functions in OpenSSL as
".byte 0xf3,0xc3".  Banish it straight to hell.
ok mlarkin, others also stared blankly
</content>
</entry>
<entry>
<title>Explicitly export a list of symbols from libcrypto.</title>
<updated>2016-12-21T15:49:29+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2016-12-21T15:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=18adabd97858ed28289c9dc31e8042c515840be4'/>
<id>urn:sha1:18adabd97858ed28289c9dc31e8042c515840be4</id>
<content type='text'>
Move the "internal" BN functions from bn.h to bn_lcl.h and stop exporting
the bn_* symbols. These are documented as only being intended for internal
use, so why they were placed in a public header is beyond me...

This hides 363 previously exported symbols, most of which exist in headers
that are not installed and were never intended to be public. This also
removes a few crusty old things that should have died long ago (like
_ossl_old_des_read_pw). But don't worry... there are still 3451 symbols
exported from the library.

With input and testing from inoguchi@.

ok beck@ inoguchi@
</content>
</entry>
<entry>
<title>Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by</title>
<updated>2016-11-04T17:30:30+00:00</updated>
<author>
<name>miod</name>
<email></email>
</author>
<published>2016-11-04T17:30:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=1a12fc8399638223feca8f853e2ac2cc22eeb471'/>
<id>urn:sha1:1a12fc8399638223feca8f853e2ac2cc22eeb471</id>
<content type='text'>
meaningful constants in a private header file, so that reviewers can actually
get a chance to figure out what the code is attempting to do without knowing
all cpuid bits.

While there, turn it from an array of two 32-bit ints into a properly aligned
64-bit int.

Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will
now always use OPENSSL_cpu_caps() and check for the proper bits in the
whole 64-bit word it returns.

i386 tests and ok jsing@
</content>
</entry>
<entry>
<title>Less S390.</title>
<updated>2016-09-04T14:31:29+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2016-09-04T14:31:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=d613aa0d6ef93fa8587113d3e866da6c582bdd0d'/>
<id>urn:sha1:d613aa0d6ef93fa8587113d3e866da6c582bdd0d</id>
<content type='text'>
ok deraadt@
</content>
</entry>
<entry>
<title>Less IA64.</title>
<updated>2016-09-04T14:06:46+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2016-09-04T14:06:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=08b60d422d5acc1a98c47af6c53680ea9cc45bc2'/>
<id>urn:sha1:08b60d422d5acc1a98c47af6c53680ea9cc45bc2</id>
<content type='text'>
ok deraadt@
</content>
</entry>
<entry>
<title>Cast Td4[] values (which are uint8_t) to uint32_t before shifting them left by</title>
<updated>2015-11-05T21:59:13+00:00</updated>
<author>
<name>miod</name>
<email></email>
</author>
<published>2015-11-05T21:59:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=06241eadbc6296ead3b3ead7f6260bc292c81890'/>
<id>urn:sha1:06241eadbc6296ead3b3ead7f6260bc292c81890</id>
<content type='text'>
24 bits; if we don't, Td4[] gets cast to signed int, and according to C&gt;=99
6.5.7, signed int shifted by enough bits to cause a the sign bit to be set
is an UB.

Reported by Pascal Cuoq on behalf of the trust-in-soft.com mafia I am
{partial,slightly related} to.
</content>
</entry>
</feed>
