This reverts commit 6495d823.

Merge c721f21f845ac832c203df791b6574caad7e9b3c into 8d62f56c

PiperOrigin-RevId: 248215345

This is the c++ analogue of cl/245028155. If we implement KeyManager based on the new "InternalKeyMananger" abstract class, users still need to be able to get the normal KeyManager interface. Hence we implement the latter based on the former.

PiperOrigin-RevId: 247924079

PiperOrigin-RevId: 247918862

PiperOrigin-RevId: 247685444

This a trivial change primarily to test Copybara migrations.

PiperOrigin-RevId: 247483967

PiperOrigin-RevId: 247411302

PiperOrigin-RevId: 247324629

PiperOrigin-RevId: 247288505

PiperOrigin-RevId: 247178796

PiperOrigin-RevId: 247178623

Merging #196.

Merge c2ccaa30 into 95aadfe7

ORIGINAL_AUTHOR=Stuart Perks <stuart.m.perks@gmail.com>
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/tink/pull/196 from perkss:perkss-tinklj c2ccaa30
GIT_ORIGIN_REV_ID=e2d678874116160c60d51941009cfa7bbb6c6409
PiperOrigin-RevId: 246866739

PiperOrigin-RevId: 246832241

PiperOrigin-RevId: 246821376

PiperOrigin-RevId: 246600038

PiperOrigin-RevId: 246523722

In bazel 0.25 the flag --incompatible_no_transitive_loads is now enabled by
default. To fix this, we must not rely on imported symbols being exported by
default.

Context: https://github.com/bazelbuild/bazel/issues/5636
PiperOrigin-RevId: 246384617

The newest version 0.25 breaks our build.

PiperOrigin-RevId: 246315462

Unfortunately, without a change, it is impossible to use the InternalKeyManager in the registry. The reason is that there is no place where the previous code [1] can be instantiated in the registry (i.e., I cannot write any code which calls [1] in the registry).

In the (to be written) function RegisterInternalKeyManager(...) I cannot call the code at [1] because it's impossible to know the primitive type for which to call it. In GetPrimitive<P> it is impossible because it's impossible to have the KeyProto type.

The only option is to call it in the constructor of http://google3/third_party/tink/cc/core/internal_key_manager.h?l=82-89&rcl=244821003. But that would mean that we have to change the interface of InternalKeyMananger (i.e., add something like a function StatusOr<shared_ptr<void*>> Create(string_view serialized_key, std::type_index type), which I think is very complicated to understand).

PiperOrigin-RevId: 246273708

PiperOrigin-RevId: 245484703

PiperOrigin-RevId: 245332714

PiperOrigin-RevId: 245326095

The issue was with grpc: https://github.com/bazelbuild/bazel/issues/4341

PiperOrigin-RevId: 245104328

Add signature length to the invalid signature error message when converting from an ECDSA signature in IEEE 1363 encoding to DER encoding.

PiperOrigin-RevId: 245071238

PiperOrigin-RevId: 243066341

Fix some issues with the ecdsa subtle polyfill when running under closure optimizations and remove base64 url padding characters for better subtle interoperability.

PiperOrigin-RevId: 242894900

Have generateKeyPair for elliptic curves return CryptoKeyPair instead of CryptoKey since it generates both a public & private key.

PiperOrigin-RevId: 242135683

PiperOrigin-RevId: 237137717

PiperOrigin-RevId: 237064147

PiperOrigin-RevId: 234869572

ECDH share with P-256K curves is not a failure.
(Of course computing an incorrect share would still fail.)
These curves are not supported by many implementations.

PiperOrigin-RevId: 232868104

PiperOrigin-RevId: 225555844

PiperOrigin-RevId: 225552379

PiperOrigin-RevId: 225551172

PiperOrigin-RevId: 225286672

PiperOrigin-RevId: 225278074

PiperOrigin-RevId: 225223930

PiperOrigin-RevId: 225197643