I think these two things were written at the same time and so the
AES-CTR-HMAC AEADs never explicitly set these values.
Change-Id: I0a142ad2b0fb9e893e290c1def5e5c6b193a3cc8
I tried so hard to get rid of AES-192, but it's called from too many
places. I suspect that those places don't actually use it, but it's
dangerous to assume that.
Change-Id: I6208b64a463e3539973532abd21882e0e4c55a1c
`cmake -GNinja .. -DCMAKE_BUILD_TYPE=Release` fails without this
patch, when building using MSVC 2013.
MSVC will detect (in release builds only, it seems) that functions that
call abort will never return, and then warn that any code after a call
to one of them is unreachable. Since we treat warnings as errors when
building, this breaks the build. While this is usually desirable, it
isn't desirable in this case.
Change-Id: Ie5f24b1beb60fd2b33582a2ceef4c378ad0678fb
Reviewed-on: https://boringssl-review.googlesource.com/3960
Reviewed-by: Adam Langley <agl@google.com>
Quite a few functions reported wrong function names when pushing
to the error stack.
Change-Id: I84d89dbefd2ecdc89ffb09799e673bae17be0e0f
Reviewed-on: https://boringssl-review.googlesource.com/4080
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Firstly, it was odd that AES-NI was a special case. Secondly, I have a
need coming up for being able to get the block function and not create a
GCM context.
Change-Id: Ie87de5e7ea42dc042d302c5eafecbc6af03c714b
Reviewed-on: https://boringssl-review.googlesource.com/3910
Reviewed-by: Adam Langley <agl@google.com>
This allows the current RC4 state of an SSL* to be extracted. We have
internal uses for this functionality.
Change-Id: Ic124c4b253c8325751f49e7a4c021768620ea4b7
Reviewed-on: https://boringssl-review.googlesource.com/3722
Reviewed-by: Adam Langley <agl@google.com>
Instead, add a separate init_with_direction hook. Normal AEADs ignore the
direction, while legacy AEADs must be initialized with it. This avoids
maintaining extra state to support the delayed initialization.
Change-Id: I25271f0e56ee2783a2fd4d4026434154d58dc0a8
Reviewed-on: https://boringssl-review.googlesource.com/3731
Reviewed-by: Adam Langley <agl@google.com>
There is exactly one implementation and it doesn't fail. Plus a cleanup
function that can fail is very bad manners; the caller has no choice but to
leak at that point.
Change-Id: I5b524617ef37bc7d92273472fa742416ea7dfd43
Reviewed-on: https://boringssl-review.googlesource.com/3564
Reviewed-by: Adam Langley <agl@google.com>
Thanks to an anonymous bug report.
Change-Id: Icdde78c82c8ee13fb64e0124712b240295677f63
Reviewed-on: https://boringssl-review.googlesource.com/3260
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Including string.h in base.h causes any file that includes a BoringSSL
header to include string.h. Generally this wouldn't be a problem,
although string.h might slow down the compile if it wasn't otherwise
needed. However, it also causes problems for ipsec-tools in Android
because OpenSSL didn't have this behaviour.
This change removes string.h from base.h and, instead, adds it to each
.c file that requires it.
Change-Id: I5968e50b0e230fd3adf9b72dd2836e6f52d6fb37
Reviewed-on: https://boringssl-review.googlesource.com/3200
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
The bsaes-armv7.S asm has an #if __ARM_ARCH__>=7 around its contents,
i.e. it's not just switched at runtime – it only compiles for >= ARMv7.
I mistakenly regressed e_aes.c in 3e652657 to always expected bsaes
functions to exist on ARM. This change fixes that.
Change-Id: Ifd9111438508909a0627b25aee3e2f11e62e3ee8
This is an initial cut at aarch64 support. I have only qemu to test it
however—hopefully hardware will be coming soon.
This also affects 32-bit ARM in that aarch64 chips can run 32-bit code
and we would like to be able to take advantage of the crypto operations
even in 32-bit mode. AES and GHASH should Just Work in this case: the
-armx.pl files can be built for either 32- or 64-bit mode based on the
flavour argument given to the Perl script.
SHA-1 and SHA-256 don't work like this however because they've never
support for multiple implementations, thus BoringSSL built for 32-bit
won't use the SHA instructions on an aarch64 chip.
No dedicated ChaCha20 or Poly1305 support yet.
Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c
Reviewed-on: https://boringssl-review.googlesource.com/2801
Reviewed-by: Adam Langley <agl@google.com>
I typoed this word and then auto-complete duplicated it all over the
place. This change fixes all the comments.
This change has no semantic effect (comment only).
Change-Id: I8952e9e71302043574757cd74a05e66500008432
RAND_pseudo_bytes just calls RAND_bytes now and only returns 0 or 1. Switch all
callers within the library call the new one and use the simpler failure check.
This fixes a few error checks that no longer work (< 0) and some missing ones.
Change-Id: Id51c79deec80075949f73fa1fbd7b76aac5570c6
Reviewed-on: https://boringssl-review.googlesource.com/2621
Reviewed-by: Adam Langley <agl@google.com>
This has been wrong since the initial rework of e_aes.c.
Change-Id: I91d92b643c151cd38a272a27f805e5f8ba6dc2df
Reviewed-on: https://boringssl-review.googlesource.com/1981
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Otherwise, in C, it becomes a K&R function declaration which doesn't actually
type-check the number of arguments.
Change-Id: I0731a9fefca46fb1c266bfb1c33d464cf451a22e
Reviewed-on: https://boringssl-review.googlesource.com/1582
Reviewed-by: Adam Langley <agl@google.com>
Since all AEAD ciphers now go through EVP_AEAD interface, the code which
uses EVP_Cipher interface no longer needs any of AEAD handling logic.
This also removes EVP_CTRL_AEAD_TLS1_AAD from GCM interface, which was
duplicating non-TLS-specific GCM logic and is not used anymore.
Change-Id: I5ddae880e7bc921337f9149a0acfdd00c9a478c3
Adam Langley
Brian Smith
Håvard Molland
David Benjamin
Adam Langley
Victor Vasiliev