ChaCha8/12/20 and GEOM ELI tests

[Gleb Kurtsou]

On (14/01/2015 08:16), rozhuk.im at gmail.com wrote:
> > >> Depends on the capabilities of the attacker.
> > >>
> > >> To be able to continuously read encrypted sectors for data
> > collection is too much.
> > >>
> > >
> > When talking about disk encryption the first assumption is that the 
> > attacker always has this capability, even with so much power the 
> > attacker shouldn't be able to break the encryption scheme. If he can 
> > then the encryption scheme is not secure.
> > 
> > Ift the attacker can learn anything about the unencrypted data or 
> > predict something about future encrypted or unencrypted blocks by 
> > analyzing the previous encrypted blocks the encryption scheme should 
> > be considered insecure.
> 
> I consider the case when the disk can be obtained by physically an attacker.
> All the rest of the disk directly connected to the computer.

Do you imply that scheme you propose will not provide support for
network storage? What about HAST, iSCSI, ATA over Ethernet, Cinder or
whatever else is fancy those days?

Documenting such limitation would make geli look terrible, not to
mention confusing..


> If an attacker can read encrypted data directly to disk means that the
> system is already compromised by an attacker,

Unless you don't have knowledge of attacker possessing such power :)

I would happily throw my encrypted disk away every time I find out it
was tempered with offline. The good thing I never know whether is has
happened (good way to save some money as well).

That is why assumption that attacker has access to encrypted disk should
hold.

In case of block device encryption overall situation is much worse.
Imagine you find out that your geli keys were compromised. There is no
mechanism provided to switch to new encryption key while retaining
access to old data and changing key for new data without creating full
copy.


> and probably in this
> case can read the data from the disk and through read() already
> decrypted and get the key from the kernel memory.