ChaCha8/12/20 and GEOM ELI tests

rozhuk.im at gmail.com rozhuk.im at gmail.com
Wed Jan 14 18:27:25 UTC 2015


> > > >> 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..

Provide, but insecure / less secure. :)


> > 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 :)

God knows everything :)
How to protect your data from God? :)


> 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.

ChaCha does not suit you.


> 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.

Technically, you can change the encryption keys geli without creating a complete copy, but if something happens in the process there is a risk of losing some data.

I think that's why it did not implement.





More information about the freebsd-geom mailing list