sunknudsen / blockcrypt Goto Github PK

I'm still exploring the code and trying to understand it. I think kdf is not set in the readme example. When compiling the example code locally, getting

Cannot find name 'kdf'.

coming from line 19:
const block = await encrypt(secrets, kdf)

I decided to write my own implementation of this scheme to play around with it and see if I could make any meaningful changes. I came up with shuffling blocks as the biggest change which could improve privacy, and at the time I hadn't noticed issue #3. It seems I hit the nail on the head with my impl for the first issue.

I also made some other unimportant design choices which can be ignored, like using aes-256-ctr (probably worse), and exporting to json. I only did this to make it easier for me to implement, as I'm also no security researcher or expert, just a hobby sec dev right now.

Here's what I came up with:
https://gist.github.com/Zytekaron/beae99b3e9a69a7ad76cbeec54347d21

This is a pretty interesting project and while I am no researcher, after stumbling on your video about it was I curious and had a look!

I think there's currently two main issues that may break your plausible deniability goal in some situations.

1. Sequential Headers

The headers and messages are encoded in the way they are provided. This can cause an issue if the "real" message is the first one.

When decoding we know which header was decoded - if we decode and it wasn't header one, we know there are other messages hidden by all the headers prior to the one we decoded.

Possible Solution:
Shuffle around the order of data and headers so that no assumptions can be made.

2. Data Length

The data length is defined "first secret ciphertext buffer length * 2 rounded to nearest upper increment of 64 bytes". This can be an issue because we can reverse this default data length to get a range for the length of the first message.

The data IV is always 12 bytes and the auth tag is 16 bytes. Given a data length, we can guess the length l of the first message to be in the following range:
0.5 * (d - 120) < l <= 0.5 * (d - 56)

So lets say we have block with a data length of 256 and an unknown number of messages.
Given the data length is 256 we can assume the length of the first message will be in the range 68 < l <= 100.

If the block is decoded and we get a message shorter than 68 bytes then we can assume this wasn't the first message in the block.
This would still be clear from issue 1 since we wouldn't decode header 1, but even if that is fixed, we know there is at least one other message hidden with the expected size constraint.

Possible Solution:
Honestly, not overly sure about this one.