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-hackers
mailing list