| 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
|
|
|
|
|
|
|
|
|
|
| |
Also document why that non-API method exists, and that we don't have
benchmarks to support the claimed optimization.
Also be more consistent about setting LOG_TAG, and fix a few old-school
copyright headers.
Change-Id: If9fdc4583eaf91275ed44e2dc56174819d1913d0
|
|
|
|
| |
Change-Id: I28dae1dfc62bd1cf134aad46e6c051eafb005723
|
|
|
|
|
|
|
|
|
|
|
| |
Also switch most non-users over to ScopedUtfChars.
Also ensure all users check that ScopedUtfChars was successful in getting the
chars.
Also rewrite ObjectInputStream and ObjectOutputStream without duplication.
Change-Id: I929d00fe3ff50b303cba4a2cf2269355e9fef5f9
|
|
|
|
|
|
|
|
| |
I've left the remaining Get/Release Critical calls in "NativeConverter.cpp"
for the next patch, even though getting into position to fix them is part of
the point of this patch.
Change-Id: I99e15a3cf3919008343ae4dc856c86ced233e07a
|
|
|
|
|
| |
Bug: 2663177
Change-Id: I87325ca8bb064b6be6c3cc3c885a8b18cceaa36c
|
|
|
|
|
|
|
|
|
|
|
| |
Get/ReleaseCritical calls.
This adds Scoped*Array classes for all primitive types, and switches all
read-only users of arrays over. At the same time, all read-only users of
Get/ReleaseCritical get switched to non-critical access.
Bug: 2663177
Change-Id: I5542cea3e24faa987ced463fcb695b9598da94af
|
|
|
|
|
|
|
|
|
| |
This change moves most of the libcore .c files to .cpp enough for them
to compile. This was largely motivated by the desire to avoid using
things like __attribute__ ((unused)) in .c files to supress warnings
in a recent change.
Change-Id: Ib967d9e16764ff805764e81362f945332080a06c
|
|
|
|
| |
Change-Id: Ied76662c470ba878cec61189acf29f5cbbd4ccd4
|
|
|
|
|
| |
Bug: 754114
Change-Id: Iaa03def509c10cbaa12fd2128584b93d4be4a6b7
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
...and switch all NPE throwers over to the helper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
If GetPrimitiveArrayCritical fails, it throws a suitable exception for us.
Also remove dead code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
| |
|
| |
|
| |
|
|
|