PiperOrigin-RevId: 264581506

Migrate the key proto format for ChaCha20/Poly1305 and XChaCha20/Poly1305 from Empty to formats specific for these types in Java.

PiperOrigin-RevId: 264579991

PiperOrigin-RevId: 264576569

PiperOrigin-RevId: 264576360

With the new KeyTypeManager implementation, tests can be made simpler.

PiperOrigin-RevId: 264572956

Migrate the key proto format for ChaCha20/Poly1305 and XChaCha20/Poly1305 from Empty to formats specific for these types.

PiperOrigin-RevId: 264569912

The tests will be migrated in a follow up cl.

*NOTE* that I change how some of the things are done. In particular, previously:
  * The underlying HMac was generated by calling the registry.
  * The underlying HMac key was manually created, without going through the registry. The version was set wrongly (to the version of the AesCtrHmacAeadKeyManager instead of the HMacKeyManager).
  * The underlying HMac key was now validated in this key manager.
  * The underlying HMac format was not validated.

After this cl, I use the HMac KeyTypeManager to validate things; and I do that directly without going through the registry.

I think the proper way would be to have some kind of registry access, where this KeyManager can obtain the new HMacKey *Type* manager, and then do the proper things. But this is complicated :/ I think this here is the second best solution.

PiperOrigin-RevId: 264568255

PiperOrigin-RevId: 264564958

the return value to StatusOr<int64_t>, to allow richer error reporting.

PiperOrigin-RevId: 264455697

PiperOrigin-RevId: 264384749

PiperOrigin-RevId: 264382855

This uses KeyTypeManagers to implement the ECIES Key Managers; making the code slightly simpler.

The main simplification happens when we update the tests in a follow up cl.

PiperOrigin-RevId: 264382557

Newer ABSL breaks CMake build.

*** Original change description ***

Bumping up ABSL-version.

PiperOrigin-RevId: 264381021

PiperOrigin-RevId: 264374853

PiperOrigin-RevId: 264336131

PiperOrigin-RevId: 264334119

PiperOrigin-RevId: 264275386

PiperOrigin-RevId: 264116863

I will add this to Tink, including cross language tests and performance testing. I think we can remove Alpha then.

PiperOrigin-RevId: 264114752

More context in cl/263529237.

PiperOrigin-RevId: 264099137

PiperOrigin-RevId: 263753529

PiperOrigin-RevId: 263752000

PiperOrigin-RevId: 263751184

We will migrate the test in an upcoming cl.

PiperOrigin-RevId: 263749532

PiperOrigin-RevId: 263748450

PiperOrigin-RevId: 263722626

This function has the contract that it doesn't need to initialize the string when resizing. At the moment, the only implementation we have is the one which does the additional work of actually resizing the string.

PiperOrigin-RevId: 263559220

With the KeyTypeManager we can now test individual functions easily, so I'll do that here.

PiperOrigin-RevId: 263558445

We also replace some memcpy instances with string operations. Context on the string replacement: cl/263529237

PiperOrigin-RevId: 263557252

In an earlier change I used string::replace, but looking at the string::replace API it feels that it is a little bit weird. Let's try to avoid it.

PiperOrigin-RevId: 263549047

PiperOrigin-RevId: 263531796

We will migrate the test in an upcoming cl.

PiperOrigin-RevId: 263530089

This removes one string copy from both encryption and decryption. When doing this, we need to ensure that we can write in the buffer underlying the string. The C++11 standard states in the relevant section 21.4.5: Returns: *(begin() + pos) if pos < size(), otherwise a reference to an object of type T with value charT(); the referenced value shall not be modified."

This is somewhat unclear: should the referenced value only not be modified in case pos = size() -- which would be a natural restriction, or should the referenced value never be modified (which would mean that string a; a[1] = 'a'; is already UB).

The second interpretation seems outrageous, and C++14 clarifies it, apparently: "operator[]: returns *(begin() + pos) if pos < size(). Otherwise, returns a reference to an object of type charT with value charT(), where modifying the object leads to undefined behavior."

I think the intention of the standard is that this works, and furthermore, I don't believe that any compiler will break this in C++11.

PiperOrigin-RevId: 263529237

Delete uses of goog.isDefAndNotNull, goog.isDef, goog.isNull, goog.isString, goog.isBoolean, and goog.isNumber.

PiperOrigin-RevId: 263407097

PiperOrigin-RevId: 263368093

We will migrate the test in an upcoming cl.

PiperOrigin-RevId: 263347373

PiperOrigin-RevId: 263318645

PiperOrigin-RevId: 263313121

Like in the corresponding commit pr/c6394fff for Tink Status, We guard it with a "#ifndef CPP_TINK_TEMPORARY_STATUS_MUST_NOT_USE_RESULT", so that users can disable this if necessary.

Note that this also only can break the build for users which compile with both -Werror and -Wunused-result -- so another option for users to disable this is to remove -Wunused-result temporarily.

PiperOrigin-RevId: 263311358

PiperOrigin-RevId: 263309980