Thor Lancelot Simon wrote:
So, you sign the public key the chip generated, and inject the _signed_
key back into the chip, then package and ship it. This is how the SDK
for IBM's crypto processors determines that it is talking to the genuine
IBM product. It is a good idea, and it also leaves
From a Computerworld blog.
--Jerry
When encryption doesn't work
By Robert L. Mitchell on Wed, 07/26/2006 - 12:00pm
In my interview with Ontrack Data Recovery this week (see
Recovery specialists bring data back from the dead:
On Thu, Jul 27, 2006 at 08:53:26PM -0600, Anne Lynn Wheeler wrote:
If you treat it as a real security chip (the kind that goes into
smartcards and hardware token) ... it eliminates the significant
post-fab security handling (prior to finished delivery), in part to
assure that counterfeit
Thor Lancelot Simon wrote:
I don't get it. How is there no increase in vulnerability and threat
if a manufacturer of counterfeit / copy chips can simply read the already
generated private key out of a legitimate chip (because it's not protected
by a tamperproof module, and the significant
Thor Lancelot Simon wrote:
So, you sign the public key the chip generated, and inject the _signed_
key back into the chip, then package and ship it. This is how the SDK
for IBM's crypto processors determines that it is talking to the genuine
IBM product. It is a good idea, and it also leaves
List,
the Subject says it all. This might be of interest
here, for comments.
The answer is definitely NO even for the naive user,
just requiring the tech-savvy for set up. Several
examples are possible.
John Smith can set two passwords, one for normal use
and the other
Thor Lancelot Simon wrote:
I don't get it. How is there no increase in vulnerability and threat
if a manufacturer of counterfeit / copy chips can simply read the already
generated private key out of a legitimate chip (because it's not protected
by a tamperproof module, and the significant
On Fri, Jul 28, 2006 at 03:52:55PM -0600, Anne Lynn Wheeler wrote:
Thor Lancelot Simon wrote:
I don't get it. How is there no increase in vulnerability and threat
if a manufacturer of counterfeit / copy chips can simply read the already
generated private key out of a legitimate chip (because
Thor Lancelot Simon wrote:
The simple, cost-effective solution, then, would seem to be to generate
static serial numbers like cipher keys -- with sufficient randomness
and length that their sequence cannot be predicted. I still do not see
the advantage (except to Certicom, who would doubtless
Thor Lancelot Simon wrote:
As Perry said, chip fabs have plenty of diagnostic equipment that
would extract an RSA private key every bit as easily as it would
extract a private serial number, which means that the additional cost
of 20-40 gates, plus IP licensing, plus... for a cryptographic
On Fri, 28 Jul 2006 10:16:23 -0400, [EMAIL PROTECTED] wrote:
Encrption can be broken
I was surprised to learn that Ontrack regularly recovers encrypted data
on systems where the user has lost the key. There's only a couple of
technologies where we would run into a roadblock [such as] some of
On Sat, Jul 29, 2006 at 04:24:12PM -0400, Thor Lancelot Simon wrote:
I cannot find any public, rigorous discussion of why such a design might
be preferable to the semiconductor noise type of design -- but I have to
assume the people designing the commercial sources have all converged on
* Steven M. Bellovin:
I wonder how accurate this is. It's certainly true that some drives have
vendor passwords to unlock them. It's hard to see how they could break
through (good) software encryption,
A lot of software tends to create temporary files in random places.
If you don't encrypt
From: Sven Dietrich [EMAIL PROTECTED]
Subject: [fc-announce] Financial Cryptography 2007 Call for Papers
To: [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 11:41:39 -0400 (EDT)
Dear Colleague,
please find below the first Call for Papers for FC'07.
Best regards,
Sven Dietrich
- --
Dr. Sven
14 matches
Mail list logo
