Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jan 2015 21:27:20 +0300
From:      rozhuk.im@gmail.com
To:        "'Gleb Kurtsou'" <gleb@freebsd.org>
Cc:        'Kimmo Paasiala' <kpaasial@gmail.com>, freebsd-geom@freebsd.org, 'Adam Nowacki' <nowakpl@platinum.linux.pl>, 'FreeBSD Hackers' <freebsd-hackers@freebsd.org>
Subject:   RE: ChaCha8/12/20 and GEOM ELI tests
Message-ID:  <54b6b50a.d17b700a.5b19.4bd3@mx.google.com>
In-Reply-To: <20150114084457.GA4099@reks>
References:  <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <54B4AE55.9090205@platinum.linux.pl> <54b5d299.4914980a.61cd.43a6@mx.google.com> <CA%2B7WWScVQ9LwQQ3NR8ipkdxroqdg26Q2dB__%2B2wRr_0kPmJODQ@mail.gmail.com> <CA%2B7WWSf%2B7N6foTKxarANfwgAitQXfxt%2B_e-HgcokzU5cVparAA@mail.gmail.com> <54b5fbbe.4457700a.2456.6944@mx.google.com> <20150114084457.GA4099@reks>

next in thread | previous in thread | raw e-mail | index | archive | help
> > > >> 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=20
> > > the attacker always has this capability, even with so much power=20
> > > the attacker shouldn't be able to break the encryption scheme. If=20
> > > he
> can
> > > then the encryption scheme is not secure.
> > >
> > > Ift the attacker can learn anything about the unencrypted data or=20
> > > predict something about future encrypted or unencrypted blocks by=20
> > > 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.
>=20
> Do you imply that scheme you propose will not provide support for=20
> network storage? What about HAST, iSCSI, ATA over Ethernet, Cinder or=20
> whatever else is fancy those days?
>=20
> Documenting such limitation would make geli look terrible, not to=20
> 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,
>=20
> 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=20
> was tempered with offline. The good thing I never know whether is has=20
> happened (good way to save some money as well).
>=20
> That is why assumption that attacker has access to encrypted disk=20
> 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=20
> 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.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54b6b50a.d17b700a.5b19.4bd3>