Respecting PURB format

[Mirtk-Srdja-Plandr]

Hello, I was wandering, does kryptor follows the PURB format (except the file name of course) ?

[hakavlad]

Yes: random-looking blob with Covert Encryption padding scheme.

First, the randomised padding scheme from Covert Encryption is used to determine the amount of padding to encrypt given the plaintext file length. The proportion SHOULD be set to 10%, which ensures very small messages are padded to at least 50 bytes.
https://www.kryptor.co.uk/specification

[hakavlad]

You can embed (action 4) kryptor files instead of tird cryptoblobs, of course.

[Mirtk-Srdja-Plandr]

Yes of course, my question was about does it leaks more information than using tird encryption. So the "Storing and carrying concealed encrypted data" is also applying to kryptor usage in combination with tird?

[hakavlad]

You could embed any random-looking files, for example:

• kryptor files
• VeraCrypt containers
• Picocrypt with Deniability mode files
• ccrypt files

[hakavlad]

my question was about does it leaks more information than using tird encryption

Probably even less: tird uses a linear formula, but the Covert Encryption padding scheme is not linear.
https://github.com/covert-encryption/covert/blob/main/docs/Rationale.md#random-padding

However, in tird, you can set a custom Max pad size % value. kryptor has no such option.

This may not matter much when embedding in random data: the embedded data will be indistinguishable from the surrounding data, and its size will not be visible.

[samuel-lucas6]

There was an interesting Cryptography Stack Exchange question related to this topic yesterday.

Also, I haven't forgotten about tird @hakavlad. I just haven't put the time aside yet to try and have a look.

[samuel-lucas6]

@hakavlad is right that encrypted files are intended to be indistinguishable from random. There's also an option to encrypt file names, which results in randomly generated file names for encrypted files.

What I will say is that I'm not following that paper's optimisation for multiple recipients (Section 3.4/Table 3).