Double-CBC as AES-KW Substitute?

Question

Background.

I'm trying to make a local command-line based password manager. So far, I've managed to make the output look dizzy on tty, and I plan to encode user credentials in individual 512-byte blocks.

To encrypt these blocks, I thought about using XTS, but the overhead of "tweaks" just makes it less favorable compared to the key wrapping modes in NIST.SP.800-38F.

But the key-wrapping in NIST.SP.800-38F involves splitting blocks in halves into "semi-blocks", which is a bit off-putting, and implementing it in full would mean the complication of various working variables.

So instead I made an ad-hoc design.

The Double-CBC.

In 2CBC mode, the plaintext goes through two rounds of encryption.

In the first round, AES-CBC is applied to the data with an all-zero IV, and because the chaining of cipher output, we can be sure that the result of the last block depends on all previous blocks.

In the second round, AES-CBC is applied again, but this time, with the last block from first round as IV, and because IV is the output of a cipher, we can be sure that it's suitably random, and because it's the output of chain of cipher, we can be sure it'd depend on all parts of the input.

I feel it'd be easier to implement 2CBC than AES-KW.

On Integrity and Semantic Security.

Because the block is large enough for the type of data it holds, it is possible to have dedicated area in the content of the 512-byte block for randomization vector and integrity check value.

Specifically, the last 128 bits will have 1.) a 96-bit randomization value, 2.) a CRC32 checksum of all previous 508 bytes.

However, I do not see a reason why message authentication is needed, as it's data at rest mostly.

However, I'm not sure if this is sufficient for the use case here. Specifically, what kind of adversary do I need to prevent tempering of the records from, and how.

The Questions.

1. Are my arguments enough to claim that 2CBC is secure for just confidentiality? Or I've made a terrible mistake and missed something important?

2. If I want to add integrity, can I do it the same way as extending KW from W?

3. Does the randomization value have to be unpredictable? Can I have meaningful information such as modification time on it? (Probably not, since if attacker checks mod time of the file, he/she will know there's some known plaintext in the file).

4. How should the need for authenticating the records be satisfied?

Answer 1

Let's assume that the final design of record structure can be altered for security and various other reasons.

1. CBC mode requires a uniformly random and unique IV for each invocation with the same key. The IV for the 2nd round is satisfied with this property with the reasons mentioned in the question.

   This is basically a deterministic pesudo-random permutation on a large block, and semantic-security could (and should) be added by adding randomization inside the block.

2. Since this question's been slashed, let's separate the concerns here.

3. Modern ciphers such as AES are currently not known to be suspectible to KPA. Since every bit of the 2CBC ciphertext is the output from AES encryption function, such concern could be said neglegible.

4. As said before, seperation of concern.

   First we should redesign the record structure, we can have 128 bytes for the site of login, 128 bytes for username, 128 bytes for password, 64 bytes for randomization. (When strings are nul-terminated, the rest of the empty area as said in the question could also be used for randomization)

   These are the contents to be encrypted using 2CBC. Next we use a separate key (assuming we have a KDF for deriving encryption and authentication keys) to HMAC-SHA512 the encrypted data and append a 64-byte MAC to the end to form a full 512-byte record.

Also remember, if you're not sure there's the need for message authentication, just have it before you find yourself having to break backword compatibility, gain should always be greater than pain.