[EMAIL PROTECTED]
Sent: Friday, June 22, 2001 11:17 PM
Subject: Re: MUSCLE Disk encryption and more
On Fri, 22 Jun 2001, Jim Rees wrote:
Ok, so you have a bunch of executables and a table of pre-computed
CRC's.
No, you have a bunch of executables, and for each you have a crypto hash
Quoting [EMAIL PROTECTED]:
On Fri, 22 Jun 2001, Jim Rees wrote:
Ok, so you have a bunch of executables and a table of pre-computed
CRC's.
No, you have a bunch of executables, and for each you have a crypto
hash
signed with a private key.
Ok.
You could store the public
Patrick Valsecchi wrote:
I don't have to store each signature of each bin into the smartcard. I won't
have enough RAM for that! I'll store inside each executable and library the
signed crypto hash. The kernel will check if the crypto hash is still the same
and the smartcard will just
Ok, it's offtopic here, but I don't think, it is a good idea
to use such policy. Why to protect such thing ??
A good policy is to setup a box and to have a model earning
money on services not on the boxes or the system (linux).
The user can do what ever he/she wants to do, if the user
.
Alex
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
- Original Message -
From: Christoph Plattner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, June 25, 2001 4:28 PM
Subject: Re: MUSCLE Disk encryption and more
Ok, it's offtopic here, but I
I don't know about the rest of it, but a former colleague of mine worked on
a secure booting system using a smartcard. I don't see anything on his web
page about it but you could contact him directly.
http://www.citi.umich.edu/u/itoi/
But if you really are concerned about very skilled hackers
On Fri, 22 Jun 2001, Jim Rees wrote:
But if you really are concerned about very skilled hackers you will need
significant hardware protection, like a processor with integrated boot code
or an epoxy potted processor and boot rom module. Even then you won't be
able to completely protect the
The user will be able to change the code, that's not the matter, but it wont be
able to run it on my customer's hardware. That's the point. And I don't this it
goes against any law neither any license.
I'm sure it doesn't go against any GPL spirit. It's even possible that my
source will be
On Fri, Jun 22, 2001 at 10:00:35PM +0200, Patrick Valsecchi wrote:
The user will be able to change the code, that's not the matter, but it wont be
able to run it on my customer's hardware. That's the point. And I don't this it
goes against any law neither any license.
I'm sure it doesn't
Aren't CRC algorithms easy to reverse?
Sorry for the sloppy terminology. Obviously this has to be a cryptographic
hash, not just a crc. But I still think performance will not be a huge
issue.
dumaguete# ls -l /bsd
-rwxr-xr-x 1 rees wheel 2172784 Jan 25 16:11 /bsd
dumaguete# time md5 /bsd
Ok, so you have a bunch of executables and a table of pre-computed CRC's.
No, you have a bunch of executables, and for each you have a crypto hash
signed with a private key.
You could store the public key in the secure rom, but this guy wants to use
a smart card, presumably because he wants
On Fri, 22 Jun 2001, Jim Rees wrote:
Ok, so you have a bunch of executables and a table of pre-computed CRC's.
No, you have a bunch of executables, and for each you have a crypto hash
signed with a private key.
Ok.
You could store the public key in the secure rom, but this guy wants
um you've got a lot of requirements that Linux may or may not be able to
meet. I think the biggest problem you're going to have is that if the user
has hardware access, the game is over anyway. Really, truly, and completely
over. Trusted hardware tends to combat this inability to be able to
13 matches
Mail list logo
