e2e key export uses strange AES-CTR construction

[cyphar]

I've been trying to implement a reader for the exported key format (so I can have a hacky way of getting around vector-im/riot-web#6454 by downloading my entire key backup and then removing the parts which I don't want to share) in Python, but have discovered that the description of the format leads to some confusion -- I had to read the matrix-react-sdk source code to understand what was going on.

In short, currently the spec says:

Serialize the JSON object as a UTF-8 string, and encrypt it using AES-CTR-256 with the key K generated above, and with a 128-bit cryptographically-random initialization vector, IV, that has bit 63 set to zero. (Setting bit 63 to zero in IV is needed to work around differences in implementations of AES-CTR.)

However, IV is a bit of a strange term for AES-CTR -- usually you would refer to a "counter" and "nonce" (which are combined in the construction to produce the IV). I imagine most people would assume that the "IV" is the nonce -- because almost all AES-CTR constructions share nonces and not initial counter values, but in your case you are sharing an initial counter value and have a zero-length nonce.

Two questions:

1. Is it possible to clarify this in the spec, since the current wording is ambiguous -- and given this is an unusual construction should be probably be pointed out.
2. Is there a particular reason for this kind of construction? Why not share a nonce like most AES-CTR constructions? Would there be an interest to release v2 of this format to change this?

[poljar]

If you're doing this in python, there already exist an implementation for this here https://github.com/poljar/matrix-nio/blob/master/nio/crypto/key_export.py as well as in the python-sdk E2E branch.

[cyphar]

I should've checked whether it existed in matrix-nio. Well it's too late now, I've already written it. 😉

[uhoreg]

As a very late (sorry) partial-answer to this, the reason for this construction seems to be simply to allow more randomness to be added. If you just use a nonce and a counter, then you have 64 bits of randomness, whereas with this construction, you get 127 bits of randomness.

Agreed, however, that there could be more words added to explain the construction. (Not to mention, that saying "Setting bit 63 to zero" is unclear, as it doesn't specify which direction you're counting bits from, and what number you start counting from.)