sunknudsen/blockcrypt

Encrypt one or more secrets with plausible deniability by design.

Blockcrypt (beta)

Encrypt one or more secrets with plausible deniability by design.

Blockcrypt is used to encrypt one or more secrets (up to 4 by default) using encrypted headers which are indistinguishable from each other and padding resulting in plausible deniability by design.

Installation

$ npm install blockcrypt

Usage (simplified for demonstration purposes)

import { encrypt, decrypt, Secret } from "blockcrypt"

const secrets: Secret[] = [
  {
    message:
      "trust vast puppy supreme public course output august glimpse reunion kite rebel virus tail pass enhance divorce whip edit skill dismiss alpha divert ketchup",
    passphrase: "lip gift name net sixth",
  },
  {
    message: "this is a test\nyo",
    passphrase: "grunt daisy chow barge pants",
  },
  {
    message: Buffer.from("yo"),
    passphrase: "decor gooey wish kept pug",
  },
]

const block = await encrypt(secrets, kdf)

console.log(block)
// {
//   salt: <Buffer 0a 89 b8 fd a1 6d 06 36 86 76 f6 e3 82 2e 54 37>,
//   iv: <Buffer bb 4e 6e 86 14 1e dc d0 ed 09 fd fd ae cc 67 8a>,
//   headers: <Buffer 50 93 bc 9b dc 28 7b 40 ab 12 4c 87 a8 eb 8b 37 d0 0d f7 1e f0 91 33 a9 ad 26 1e 14 73 1a 32 6d bd cf a9 7b 0a 67 97 78 ee c8 95 c5 28 ae ac ad 5f 2d ... 14 more bytes>,
//   data: <Buffer 4e 2f bc 42 3e 88 1e 35 d8 cb 88 ff 4f 43 60 6f 02 5f f2 81 f6 f7 b8 32 84 80 e3 a9 c5 fe f0 0b 02 b9 cc c8 be 06 d3 d4 85 96 62 cc 0a 27 0e 5d 61 4a ... 334 more bytes>
// }

const message = await decrypt(
  "grunt daisy chow barge pants",
  block.salt,
  block.iv,
  block.headers,
  block.data,
  kdf
)

console.log(message)
// <Buffer 74 68 69 73 20 69 73 20 61 20 74 65 73 74 0a 79 6f>

console.log(message.toString())
// this is a test
// yo

blockcrypt's Issues

Plausible deniability improvement / custom impl

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

Plausible deniability caveats

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.

kdf value is not set in README.md example

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)