Adiantum has an interesting claim...

[Chris M. Thomasson]

The following text from:
__________________________
"Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block
mode: changing any bit anywhere in the plaintext will unrecognizably
change all of the ciphertext, and vice versa"
__________________________

https://keybase.pub/stefan_claas/software/adiantum/


Is basically identical to my claims in my HMAC cipher here:

http://funwithfractals.atspace.cc/ct_cipher

__________________________
1. Introduction
The cipher uses propagation of HMAC digest bytes to achieve a radical
diffusion of a plaintext within its ciphertext, and vise versa. It has
the following basic properties:

1: Every encryption of the same plaintext creates a radically different
ciphertext.

2: If a single bit of a ciphertext is altered, it decrypts into a
radically different plaintext.
__________________________

Claims 1 and 2... So my idea is not so crazy!

I showed my cipher to a Google engineer around a year and a half ago.
This is freaky!

[Chris M. Thomasson]

On 12/3/2019 5:55 PM, Chris M. Thomasson wrote:
> The following text from:
> __________________________
> "Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block
> mode: changing any bit anywhere in the plaintext will unrecognizably
> change all of the ciphertext, and vice versa"
> __________________________
>
> https://keybase.pub/stefan_claas/software/adiantum/

Shit! Sorry. Got the wrong link. Here it is:

https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html

[Chris M. Thomasson]

They even used vise-versa! Very odd. Humm...

[Max]

It's not crazy, freaky or odd. Confusion and diffusion are the main
properties of secure encryption, formulated by Shannon in 1945. But
applying this principle to "wide" amounts of data comes at a cost. Every
time a single bit of the plaintext, say your 1 TB database, is changed, the
whole plaintext has to be re-encrypted. Also, if encrypted data is
tranferred, it can not be decrypted, before the complete (!) ciphertext has
been received. Also, paralell processing is severly thwarted.
That's why "narrow block" encryption is used, despite its theoretically
lower level of security (encryption and authentication).

If I got any of your considerations wrong and/or missed the point of your
post, please correct me.

Cheers,

Max

[Chris M. Thomasson]

Correct. Therefore, it might be useful to encrypt so called "finished"
projects. We have these blueprints for an interesting invention. They
are finished. We encrypt the file, disk, (s) using a special password,
or crypto secure HMAC key in my case. Now, this finished project is set
in stone wrt bit level mutations, agreed? Well, the user needs to
understand that this is not meant, at least my algorithm, to encrypt a
current running hd...

It is meant to encrypt things that are done, so to speak. So, one can
encrypt multiple files with different names under the same key, the fun
part is that each ciphertext will be different even if the files
(plaintexts) are all _identical_.

Will get back to you after New Years. Thanks for your highly informative
response. You point out some severe flaws wrt common usage patterns. Thanks.

[Chris M. Thomasson]

On 12/31/2019 12:10 AM, Chris M. Thomasson wrote:
> On 12/30/2019 5:00 PM, Max wrote:

[...]

>> If I got any of your considerations wrong and/or missed the point of your
>> post, please correct me.
>
>
> Correct. Therefore, it might be useful to encrypt so called "finished"
> projects. We have these blueprints for an interesting invention. They
> are finished. We encrypt the file, disk, (s) using a special password,
> or crypto secure HMAC key in my case.

Actually the crypto secure HMAC key is a single part of the main key in
my system. Adiantum is very interesting to me. Fwiw, to other readers,
here is my secret key:
__________________________________
2. The Secret Key
Both properties of my cipher rely on a good cryptographic hash function.
HMAC is an abstract layer on top of a hash algorithm that allows for a
secret key. Let us refer to this HMAC key as SK.hmac_key from now on. We
also need to allow Alice and Bob to choose a hash to use with HMAC. Let
us refer to this as SK.hash_algo. The size of HMAC's digest in bytes is
based on the digest size of SK.hash_algo. For example, SHA-256 has
32-byte digests.

Another aspect involves prepending random bytes from a TRNG to the front
of a plaintext. Let us refer to the number of these random bytes as
SK.rand_n. Okay, the secret key SK used by Alice and Bob is comprised of:
_________________________________
SK.hmac_key = Key for HMAC.
SK.hash_algo = The Hash Algorithm.
SK.rand_n = The Number of TRNG bytes.
_________________________________
SK.hmac_key must be a cryptographically secure password, e.g. comprised
of 1024 bytes from a TRNG.

SK.hash_algo must be a cryptographically secure hash, e.g. SHA-384.

SK.rand_n must be equal to, or ideally larger than the digest size of
SK.hash_algo.
__________________________________

[...]

[Max]

Could you summarize and maybe even quantify the advantages your approach has
compared to blocksizes of 128 or 256 bits?

Cheers and a swell New Year's Eve to you!

Max

[Chris M. Thomasson]

Its wide block such that data is secured from front to back. There is no
scenario where we can isolate blocks, say we know the plaintext. We know
that the first few blocks will contain this data. Now, in my wide block,
actually plaintext block-wide cipher, this cannot occur, or it is very
difficult. Look at the reversal in section:

3.2 The CRYPT Function

in the pseudo-code:
3: Set C_1 to the bytes of C in reverse order.

This gives me 100% bit level sensitivity.

>
> Cheers and a swell New Year's Eve to you!

To you as well! Thanks again.

[Chris M. Thomasson]

On 12/31/2019 9:15 AM, Max wrote:

[...]

This of a quasi known plaintext attack. Perhaps something like:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

We know a certain structure. In a block cipher we can infer that certain
data is in the first several blocks. In my wide block cipher, where the
size of the plaintext plus its prepended TRNG bytes, is the whole block.
There is no way to break it apart into components.

However, I can create a new version that artificially sets a block size
to be smaller than the whole. Each individual block would be bit
sensitive, instead of the whole. Take a plaintext size divide it by say,
7, this is the block size except for the final block which may be larger
to handle remainders. Afaict, this is not as secure as a wide block.

[Samuel Allan]

Chris M. Thomasson wrote:
> This of a quasi known plaintext attack. Perhaps something like:
>
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
>
> We know a certain structure. In a block cipher we can infer that certain
> data is in the first several blocks. In my wide block cipher, where the
> size of the plaintext plus its prepended TRNG bytes, is the whole block.
> There is no way to break it apart into components.
>
> However, I can create a new version that artificially sets a block size
> to be smaller than the whole. Each individual block would be bit
> sensitive, instead of the whole. Take a plaintext size divide it by say,
> 7, this is the block size except for the final block which may be larger
> to handle remainders. Afaict, this is not as secure as a wide block.
>

The link doesn't exactly explain how one could mount a known-plaintext
attack. What's more, secure modes such as AES-CBC with a random IV (when
done properly) are provably resistant to CPA/KPA as long as the
following are met:
(a) you encrypt less than 2^(n/2) blocks where n is the block size (for
AES-128 this is 2^64)
(b) The cipher itself (AES) is resistant to CPA/KPA

The advantage of building in blocks (first the primitive, then the mode
of operation, e.t.c.) is that often you can *prove* that a certain
construction is secure as long as all its elements are secure.

On the other hand, if you bundle everything up without separating into
layers, proving that the security of something relies on anything
becomes impossible. It just becomes a giant mess which people have to
*hope* is secure.

If you want bit level sensitivity, create a primitive C = CHRIS(P, K)
which is a regular block/stream cipher which gives the same ciphertext
for the same plaintext and vice versa, and THEN use this primitive in a
mode that supplies bit-level sensitivity (such as Adiantum or PCBC mode).

In this case you will be able to reduce the requirements of the CHRIS
function to simply behaving like a random function. The PCBC will
automatically take care of the bit-level sensitivity and there is no
need to take care of it in the cipher.

Bonus point: your encryption system will become much more versatile, you
could be able to use it as a stream cipher in CHRIS-CTR mode, for disk
encryption in CHRIS-XTS mode, e.t.c.

If curious you can read re the PCBC mode here:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Propagating_Cipher_Block_Chaining_(PCBC)

[Chris M. Thomasson]

On 2/24/2020 9:40 PM, Samuel Allan wrote:
> Chris M. Thomasson wrote:
>> This of a quasi known plaintext attack. Perhaps something like:
>>
>> https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
>>
>> We know a certain structure. In a block cipher we can infer that
>> certain data is in the first several blocks. In my wide block cipher,
>> where the size of the plaintext plus its prepended TRNG bytes, is the
>> whole block. There is no way to break it apart into components.
>>
>> However, I can create a new version that artificially sets a block
>> size to be smaller than the whole. Each individual block would be bit
>> sensitive, instead of the whole. Take a plaintext size divide it by
>> say, 7, this is the block size except for the final block which may be
>> larger to handle remainders. Afaict, this is not as secure as a wide
>> block.
>>
>
> The link doesn't exactly explain how one could mount a known-plaintext

Well, think of a stream of ciphertext.

ABCDEFG

Eve alters the third symbol in, 'C'.

ABXFTGH

Notice how A and B stay the same? Imvvvho, this might be a vector for an
attack. Fwiw, this cannot happen in my experimental cipher.

[Samuel Allan]

Chris M. Thomasson wrote:
>
> Well, think of a stream of ciphertext.
>
> ABCDEFG
>
> Eve alters the third symbol in, 'C'.
>
> ABXFTGH
>
> Notice how A and B stay the same? Imvvvho, this might be a vector for an
> attack. Fwiw, this cannot happen in my experimental cipher.
>
>

There is absolutely no way to use this for an attack because stream
ciphers are not used in this way. Stream ciphers are used with a random
IV and authentication, meaning that changing any character of the
ciphertext in this way will prevent the recipient from decrypting it.

This is why people use modes - you can ensure all the bit level
sensitivity, security, e.t.c. By simply using the correct mode of
operation. Designing the cipher then becomes much much easier (you simly
have to build a CSPRNG instead of worrying about all this stuff).

[Chris M. Thomasson]

Think of a domino effect vs a full blown 100% avalanche effect on the
whole ciphertext.

[Samuel Allan]

Chris M. Thomasson wrote:

> Think of a domino effect vs a full blown 100% avalanche effect on the
> whole ciphertext.

Domino or full blown, e.t.c. doesn't actually make a difference on its
own - you need context.

Within a block cipher diffusion needs to be complete *not because
diffusion is a magical property that is good, and not because lack of
diffusion can be used for attacks but merely because and ONLY because if
you have bad diffusion it likely means your function is strongly
non-random, and a strongly non-random function is exploitable with OTHER
MEANS.*

On the other hand, diffusion makes no difference in a stream cipher
because there is an information-theoretic guarantee that the cipher will
be secure if (and only if) the CSPRNG is indistinguishable from random.
As soon as you have a CSPRNG indistinguishable from random you can put
all ideas such as bit level sensitivity, e.t.c. down the toilet because
you now have an information-theoretic guarantee that the cipher is secure.

TL;DR: Strive for a secure cipher vs a 'diffuser' cipher. Also diffusion
makes sense only in certain contexts (like block cipher).

[Samuel Allan]

Chris M. Thomasson wrote:
>

By the way, please excuse me for any harshness in my previous reply - I
was in a very bad mood (not that that is a good excuse).