0

I know this is theoretically bad practice, but please bear with me…

Assuming following spec:

  • Salt and IV are randomly generated using cryptographically-secure RNG.

  • Argon2 is used as KDF so key_1=Argon2(shared_salt, passphrase_1) and key_2=Argon2(shared_salt, passphrase_2).

  • Both passphrases are not vulnerable to dictionary attacks and the like.

  • Shared salt and IV are only (re-)used once in the context of singular concatenated encrypted paper backup.

Encrypted paper backup = concat(shared_salt, shared_iv, AES-256-CBC(shared_iv, key_1, "some text"), AES-256-CBC(shared_iv, key_2, "some other text"))

According to https://crypto.stackexchange.com/a/10511/83430, it appears above spec should hold up to pretty sophisticated attacks (if vulnerable at all).

See proof of concept.

sunknudsen
  • 199
  • 8
  • This seems to be the same question you posted before, except you're now mentioning that it's for paper backups. As you were talking about VeraCrypt before, please can you clarify what that means and how it's related to plausible deniability. I really don't understand what you're trying to achieve. – samuel-lucas6 Sep 07 '22 at 20:01
  • Thanks for helping out @samuel-lucas6. Researching encryption schemes that could yield similar results to VeraCrypt hidden volumes, yet with as many “hidden” secrets as one needs and in a form that can be printed using QR codes. – sunknudsen Sep 07 '22 at 20:10
  • Forensic Analysis breaks the plausible deniability of Veracrypt linked in this answer... – kelalaka Sep 07 '22 at 23:04
  • @sunknudsen Each passphrase has to be unique to avoid deriving the same key. It would be safer using a separate salt for each passphrase, just prepending it to each ciphertext if they're going to be fixed in length anyway. – samuel-lucas6 Sep 08 '22 at 08:30
  • @samuel-lucas6 Challenge is we don’t know where each secret starts in ciphertext therefore using separate salt is not possible. Have you looked at https://github.com/sunknudsen/blockcrypt/blob/master/src/index.ts? – sunknudsen Sep 08 '22 at 09:55
  • @kelalaka Have a moment to look at https://github.com/sunknudsen/blockcrypt/blob/master/src/index.ts? Thanks for link about VeraCrypt… will read up. – sunknudsen Sep 08 '22 at 09:55
  • @kelalaka Putting together a scientific committee for a project I am developing. Would love to pick your brain… please reach out if you wish to learn more. https://sunknudsen.com/ – sunknudsen Sep 08 '22 at 10:08
  • 1
    When we talk about IV reuse we talk about it in the context of a specific key. If you are using your IV for mathematically unrelated keys then it is not really reuse. – Maarten Bodewes Sep 08 '22 at 12:01
  • 1
    @sunknudsen If you don't know where each secret starts, how can it be decrypted? Did you look at the PURBs paper I linked before? – samuel-lucas6 Sep 08 '22 at 12:41
  • @samuel-lucas6 Great question… please see https://github.com/sunknudsen/blockcrypt/blob/master/src/index.ts#L66-L111. Decryption function parses (iterates though) ciphertext which works very well for small “block” sizes. BlockCrypt also outputs needles (essentially words) which one can memorize and input to massively speed up parsing. – sunknudsen Sep 08 '22 at 13:20
  • @MaartenBodewes Thanks for joining conversation… have a moment to peer review https://github.com/sunknudsen/blockcrypt/blob/master/src/index.ts? The whole logic is about 100 lines of code. Would love to know what you think. – sunknudsen Sep 08 '22 at 13:22
  • @samuel-lucas6 Looks like what I designed unknowingly is very similar to a PURB, but, hopefully, with added plausible deniability by design. – sunknudsen Sep 08 '22 at 13:35

0 Answers0