And 'the public' doesn't include people like government level attackers?
People like cryptography experts? People who like to play with things like
this?
No it doesn't. *It's not in the threat model.*
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology htt
Just to clarify...
I'm NOT saying that any particular piece of "secure" hardware can never be
broken. Steve Weingart (the hw security guy for the 4758) used to insist that
there was no such thing as "tamper-proof." On the HW level, all you can do is
talk about what defenses you tried, what att
Thus spake Rich Salz ([EMAIL PROTECTED]) [11/09/03 08:51]:
> > You propose to put a key into a physical device and give it
> > to the public, and expect that they will never recover
> > the key from it? Seems unwise.
>
> You think "the public" can crack FIPS devices? This is mass-market, not
> g
/enforcer open-source TCPA project
On Wed, 10 Sep 2003, Sean Smith wrote:
>
>> So this doesn't
>> work unless you put a "speed limit" on CPU's, and that's ridiculous.
>
>Go read about the 4758. CPU speed won't help unless
>you can crack 2048-bit
Rich Salz <[EMAIL PROTECTED]> writes:
>Second, if the key's in hardware you *know* it's been stolen. You don't know
>that for software.
Only for some definitions of "stolen". A key held in a smart card that does
absolutely everything the untrusted PC it's connected to tells it to is only
margin
> You propose to put a key into a physical device and give it
> to the public, and expect that they will never recover
> the key from it? Seems unwise.
You think "the public" can crack FIPS devices? This is mass-market, not
govt-level attackers.
Second, if the key's in hardware you *know* it's
>You propose to put a key into a physical device and give it
>to the public, and expect that they will never recover
>the key from it?
It's been on the market for six years now; so far, the foundation
has held up.(We also were darn careful about the design
and evaluation; we ended up earning
On Wed, 10 Sep 2003, Sean Smith wrote:
>
>> So this doesn't
>> work unless you put a "speed limit" on CPU's, and that's ridiculous.
>
>Go read about the 4758. CPU speed won't help unless
>you can crack 2048-bit RSA, or figure out a way around
>the physical security, or find a flaw in the applic
> So this doesn't
> work unless you put a "speed limit" on CPU's, and that's ridiculous.
Go read about the 4758. CPU speed won't help unless
you can crack 2048-bit RSA, or figure out a way around
the physical security, or find a flaw in the application.
> Yes. Protocol designers have been exp
On Tue, 9 Sep 2003, Sean Smith wrote:
>>
>> >How can you verify that a remote computer is the "real thing, doing
>> >the right thing?"
>>
>> You cannot.
>
>Using a high-end secure coprocessor (such as the 4758, but not
>with a flawed application) will raise the threshold for the adversary
>signi
>
> >How can you verify that a remote computer is the "real thing, doing
> >the right thing?"
>
> You cannot.
Using a high-end secure coprocessor (such as the 4758, but not
with a flawed application) will raise the threshold for the adversary
significantly.
No, there are no absolutes. But ther
On Mon, 8 Sep 2003, Sean Smith wrote:
>How can you verify that a remote computer is the "real thing, doing
>the right thing?"
You cannot.
>In contrast, this code is part of our ongoing effort to use open
>source and TCPA to turn ordinary computers into "virtual" secure
>coprocessors---more pow
12 matches
Mail list logo
