ChaCha8/12/20 and GEOM ELI tests

[rozhuk.im at gmail.com]

> > > > > Maybe faster but a stream cipher is unusable for disk
> encryption
> > > > > - iv is derived from sector number and doesn't change. Being
> > > > > able to write a known plaintext and read resulting ciphertext
> > > > > allows you to recover the cipher stream and decrypt any past or
> > > > > future data
> > > stored
> > > > > on that sector.
> > > >
> > > > Depends on the capabilities of the attacker.
> > > >
> > > > To be able to continuously read encrypted sectors for data
> > > > collection is too much.
> > >
> > > I disagree. It's the most basic attack scenario. Assuming attacker
> > > was able to get access to encrypted disk once, odds are high it may
> > > happen again.
> >
> > From different types of threats, there are various means of
> protection.
> > AES-XTC more universal solution, encryption ChaSha more specialized.
> > Each solution has its pluses and minuses.
> 
> "various means of protection" is rather confusing. It's either
> acceptable for disk encryption or not.
 
This is acceptable for disk encryption in certain conditions: need speed and have the assurance that an attacker does not have access to the data flow while the disk is mounted.


> > AES too slow for me, and options when someone magically going to read
> my encrypted disk excluded.
> > In my particular case.
> 
> It's widely accepted threat model (as was also mentioned elsewhere). So
> it's rather your particular use case that has magic vibe to it.

In my case, home use, my data is not so important to arrange a targeted attack on the home server.
Moreover, in the case of targeted attack, there is often much easier ways to get the unencrypted data than analyzing encrypted disk sectors.
I need to encrypt the case if the server can steal or take by force.
So I think that for me personally for my purposes ChaCha is more appropriate than AES-XTS.

I am sure many other users will also be happy to get a faster encryption in exchange for the possibility of targeted attacks unlikely.



> > > > Ability to read encrypted sectors has a transmission network, for
> > > example when the container=disk is stored somewhere in the cloud.
> > > >
> > > > In many cases, the attacker gets Encrypted disk along with other
> > > equipment, often in the off state.
> > > > Without encryption keys and the ability to write / read through
> > > > the
> > > GELI.
> > > >
> > > > I do not see any weaknesses stream ciphers in cases when the
> > > > attacker
> > > is not able to access the disk when it is mounted in the GEOM GELI.
> > > >
> > > > Another possibility is the use of ChaCha (without XTS) -
> > > > encryption swap file: there every time a new key is generated,
> > > > besides the speed is particularly important.
> > >
> > > Stream cipher (or similarly functioning block cipher mode) should
> > > not be used for disk encryption. IMHO swap encryption hardly
> > > justifies adding insecure encryption mode to geli. Fast swap is
> > > certainly nice to have, but rather remains a snake oil, system will
> > > remain trashed due to swapping no matter how fast swap is.
> >
> > Can you describe what is weak encryption swap with ChaCha?
> 
> Stream cipher, as is, is not acceptable for disk encryption. I think we
> all agree on that.

Stream cipher disks acceptable in certain cases.


> It remains secure as soon as the same key stream is not used twice.
> By writing data to the same sector one breaks this requirement.
>
> I'm not objecting that there is a possibility of building swap
> encryption on top of stream cipher, but that is likely not to be
> trivial and would require careful design review. Although I don't see
> how block device "encrypted" with stream cipher can be secure under
> assumption that attacker has access to the disk.

It all has no value if the attacker has no way to get multiple copies of the same sector with different data.


> BTW You may want to get rid of SHA in g_eli_crypto_ivgen() for ChaCha
> in pursue for yet higher performance.

IV = SHA256(key, sector num)
ChaCha8-256       = 353804761 bytes/sec
ChaCha12-256      = 299028184 bytes/sec
ChaCha20-256      = 225262046 bytes/sec
XChaCha8-256      = 347179985 bytes/sec
XChaCha12-256     = 289285124 bytes/sec
XChaCha20-256     = 219787078 bytes/sec

IV = sector num
ChaCha8-256       = 376476930 bytes/sec
ChaCha12-256      = 312266331 bytes/sec
ChaCha20-256      = 233636775 bytes/sec

XChaCha has a 192-bit IV, so I would prefer to get IV from the hash.


> As far as I remember Salsa20 has this nice property of letting one
> start encryption from arbitrary offset in the stream, I assumed that
> you are using the same in ChaCha for geli. Although having looked at
> the code it is not that obvious what is going on. There is a method to
> set iv being used, but not to change counter (stream offset). Is that
> intentional? Do we reset key for each geli sector to be encrypted?

chacha_iv_set() does not reset key.
xchacha_set_key_iv_rounds() require key and IV.
chacha_counter_set() - set block counter.

chacha_key_set() - copy key and constant to chacha context.