soter: Support uncompressed EC keys

[ilammy]

Themis can accept uncompressed public keys already. But it also performs paranoid checks that keys have exactly the size they should have, with all implementation choices and quirks. Newer implementations of Themis avoid those quirks and use uncompressed format for efficiency. Make sure such keys are accepted by this Themis.

Note: Themis still produces compressed keys, as before. However, it is now able to read uncompressed keys produced... elsewhere.

Checklist

• Change is covered by automated tests
  • The tests actuall pass lol
• Benchmark results are attached (not important)
• The coding guidelines are followed
• Changelog is updated (in case of notable or breaking changes)

[vixentael]

It doesn't break backwards-compatibility; it gives compatibility with elsewhere. I like it.

[Lagovas]

yay, when I saw Support uncompressed EC keys subject, I was hoping that you added a directive that turns on using uncompressed keys in themis and it will generate ciphertexts and keys in uncompressed form)

[ilammy]

I was hoping that you added a directive that turns on using uncompressed keys in themis

That should be relatively easy to add as well. Update this line:

themis/src/soter/openssl/soter_ec_key.c

Lines 155 to 160 in 5d4a0b7

	!= EC_POINT_point2oct(group,
	Q,
	POINT_CONVERSION_COMPRESSED,
	(unsigned char*)(key + 1),
	output_length - sizeof(soter_container_hdr_t),
	NULL)) {

and a bunch of others for public key sizes, and the same thing for BoringSSL.

Though, I dunno whether it's worth doing, since downstream projects might be hardcoding key sizes and they'd be in for a surprise if the layout changes. Well, they'd have to deal with it when migrating to Themis NG, but that sounds more justified than having to deal with it during run-of-the-mill 0.14 → 0.15 upgrade (if it ever happens, haha).

I'm not particularly keen on redesigning key generation API to support this, but maybe some other option will do? Say, THEMIS_USE_UNCOMPRESSED_KEYS=1 environment variable? Some magic global state in the library? A blessed function in GoThemis to decompress a key?

How badly do you want time savings from not having to decompress keys?

I don't have numbers handy to copypaste them, but my benchmarks show that ECDH outstrips key decompression by quite a large margin. If anything, I'd rather fix Secure Message implementation to avoid doing ECDH twice, which would be much greater boost to performance than generating uncompressed keys – and with zero compatibility concerns.

Opinions, @Lagovas, @vixentael?

[Lagovas]

It was just opinion. I remember, that it is easy to do (same as you described). But not an idea to do as next step.

Say, THEMIS_USE_UNCOMPRESSED_KEYS=1 environment variable?

Yeah, I thought about that approach because it save backward compatibility but allows to turn on manually if you know what to do and what you want.

How badly do you want time savings from not having to decompress keys?

As I remember, it saved ~30% of time in secure message logic. The most complicated operations in secure message algorithm is decompressing point because deals with big numbers to calculate Y. You do to computation of shared key that uses big nums too. And then using symmetric encryption after KDF to encrypt data using with a shared key. And point decompression looks like expensive operation which can be avoided by spending more storage space.

[vixentael]

Say, THEMIS_USE_UNCOMPRESSED_KEYS=1 environment variable?

+1 to this approach. But I think that we should not change the default settings for the current Themis to avoid backwards compatibility issues, rather just to implement this option for our own needs & compatibility with Themis NG.