Robert Millan wrote:
> On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote:
>>> If the code that does the authentication is loaded from the encrypted
>>> partition,
>>> without being checked, this is true, but we assume, that core.img is already
>>> loaded (and checked), so the authentication
On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote:
>> If the code that does the authentication is loaded from the encrypted
>> partition,
>> without being checked, this is true, but we assume, that core.img is already
>> loaded (and checked), so the authentication code is not on the encrypte
If the code that does the authentication is loaded from the encrypted partition,
without being checked, this is true, but we assume, that core.img is already
loaded (and checked), so the authentication code is not on the encrypted
partition, and can detect any tampering.
As far as I understood Rob
I stand corrected; But in that case, measurement can still be implemented
at the filesystem level?
Yes it can be done. Most common way is to attach a mac to every sector
(like a signature but uncheckable without the key). One could also
implement mac on filesystems like btrfs. It doesn't solv
phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the
>> data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt. Is this correct?
>>
> It's not. Encryption is permutation
> E_{key,sector} (P) -> C
> Which permutes
On Fri, Feb 27, 2009 at 11:55:55PM +0100, phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt. Is this correct?
>>
> It's not. Encryption is permutation
> E
I'm no crypto expert, but I was under the impression that when the data is
encrypted, measurement comes "for free": if someone tampered it, you'd be
unable to decrypt. Is this correct?
It's not. Encryption is permutation
E_{key,sector} (P) -> C
Which permutes transforms plaintext P to cipherte
On Fri, Feb 27, 2009 at 10:56:48PM +0100, Jan Alsenz wrote:
> > Hi,
> >
> > The last stage is much simpler. Just put /boot/ in a crypted filesystem (we
> > have a patch liing around which is pending to merge).
>
> Yes, that would also be an idea.
> Then the filesystem needs the authentication.
The last stage is much simpler. Just put /boot/ in a crypted filesystem (we
have a patch liing around which is pending to merge).
Yes, that would also be an idea.
Then the filesystem needs the authentication.
Encrypted filesystems don't prevent some attacks as inconsistent
rollback. Suppose th
Robert Millan wrote:
> On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote:
>> If we could agree on this, then I think we could find a way to extend the
>> GRUB
>> module system to fully allow this.
>>
>> From my point of view the minimal needed features for these systems are:
>> - easy exc
10 matches
Mail list logo
