| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
external/bouncycastle
- Change to be the primary build for bouncycastle sources (as opposed to part of libcore)
- Moved OpenSSLMessageDigest from libcore to OpenSSLDigest
It uses NativeCrypto API from core, but implements a bouncycastle specific interface
- restored registration of bouncycastle MessageDigests for SHA-1, SHA-256, MD5
OpenSSLProvider versions take precedence, but explicit provider of "BC" allows choice
- enabled native versions of SHA-384 and SHA-512
- pruned MD4 implementation
frameworks/base
- frameworks and CoreTests modules now depend on bouncycastle
- update preloades classes for NativeBN package change
- moved CryptoTest to libcore
libcore
- core now builds without bouncycastle sources
- core-tests, core-tests-support, core-tests-supportlib now depend on bouncycastle
- removed libcore/openssl directory, moving NativeBN to java/math
- minor cleanup of Provider, Security, Services style while working on ProviderTest
- added new OpenSSLProvider registered as first provider to have
priority over the others to ensure our native implementations are used
- moved BouncyCastle to have priority as a provider over Harmony
- JarVerifier and JarUtils now implicitly use OpenSSLMessageDigest
- Cleanedup OpenSSLSignature, implementation needs to be finished to move to OpenSSLProvider
- To avoid using PEMWriter from BouncyCastle, NativeCrypto now takes binary encoded certs and keys
This is more efficient as well avoiding the base64 decode/encode of the binary data
- removed SHA-224 to match the RI
packages/apps/CertInstaller
- CertificateInstaller module now depends on bouncycastle
this is the only app to depend on bouncycastle
system/core
- updated BOOTCLASSPATH
Change-Id: I6205366b12baec4331b4a76e2c85d8324bf64b2c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were sharing an openssl BN_CTX between threads, which is unsafe. Stop
doing that, creating BN_CTXes on demand (which seems to be what openssl
does internally). For 1024-bit integers, this makes division faster,
multiplication slower, and makes no convincing difference to gcd. I
instrumented a build to report any time one of the methods that needs
a BN_CTX gets called, and couldn't find anywhere they're used during
boot or https browser usage. (These things do use BigInteger; they just
don't use the methods this change affects.)
Bug: 2652542
Change-Id: I98c94b41df95566cb4c8598f299911e641f72f63
|
| |
|
|
|
| |
Bug: 2663177
Change-Id: I87325ca8bb064b6be6c3cc3c885a8b18cceaa36c
|
| |
|
|
|
|
|
|
|
| |
The >= versus > bug was fixed in openssl somewhere between .98g and .98k (we
don't have _all_ versions conveniently lying around), and our removal of
the disjunct was irrelevant. Call the now-correct upstream code instead of
manually inlining and hacking it.
Also rename BN_lshift to BN_shift, since it handles both left and right shifts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
valgrind complains about invalid 4-byte reads, caused by "case 8" in the
BNInterface.c function I'm removing here, which assumed that if we're checking
whether a BIGNUM fits in 8 bytes, it must require more than 4 bytes (and so
accessing d[1] is acceptable).
We can implement this in Java using the existing BigInteger.bitLength
method (which may call down to native code, but that native code looks okay).
Also remove a related commented-out method.
Bugs: 2223213, 2225642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeBN_bn2twosComp doesn't do what it claims to: it's an exact copy of
NativeBN_BN_bn2bin (observe which OpenSSL BN_ function it calls!), and -- from
the OpenSSL documentation -- that function "converts the absolute value of [its
argument] into big-endian form".
OpenSSL doesn't actually sport any appropriate function to call here, but
luckily this code isn't called anywhere, and so can be removed.
(BigInteger.toByteArray -- the most likely caller of this code -- seems to
do the right thing, using Java code to make a big-endian two's-complement
byte[]. Likewise, the conversion from a big-endian two's-complement byte[]
for the corresponding BigInteger constructor looks right too, using native
code to twiddle the bits itself.)
|
| | |
|
| | |
|
| |
|
