ArcotSign (was Re: Does security depend on hardware?)

[from a discussion of tamper-resistant hardware for payment systems
on dbs@philodox.com, a mailing list dedicated to digital bearer systems,
where Scott Loftesness, of DigiCash and Arcot Systems, mentioned ArcotSign.]

You mentioned the URL for Arcot, and I looked at the site.  It seems
rather lacking in technical details, and makes a very strong claim --
that it can provide tamper resistance in software on a hardware/OS/etc.
platform which is generally hostile (a general purpose computer).

I noticed that there are some big name cryptographers signed 
on as advisors -- Hellman and Schneier, who make some pretty 
glowing comments about the product.  I'm not generally swayed by anything 
but mathematics, physics, and logic when it comes to cryptography and 
security, despite generally agreeing with the analyses of those 
cryptographers.

I can see a couple of ways you could approximate real security using 
untrusted hardware -- either a one time password system retained by
the user (I've investigated this in the past, and it generally ends
up being a hardware token or a printed book of codes), or a remote
system like Kerberos where there exist out of band key protection 
mechanisms, or it's not real security.  I'd love to be convinced
otherwise, particularly if the technology will be available for
others to license.

I also noticed that the system is patent pending -- this would seem
to rule out the existing hardware token/one time pad system, or the
Kerberos-style central authentication server releasing security credentials
when presented with a passphrase system, as there are decades of prior
art in each encompassing all reasonable variations.  I guess this means it's
something new and interesting -- I'm sure everyone would be interested
in details.

Of course, in any system where all you do is authenticate yourself
to a remote system, but you're not provided with a link directly
between the user and the remote authority guaranteeing 
Confidentiality, Integrity, and Authentication, you can't really
make any claims other than that the user has authenticated herself
to some server -- any transactions the user could do are subject to
a man in the middle attack, so while the user has successfully authenticated
themselves to a remote server, and signed that *some* transaction
is acceptable, there's really no legal assurance that the user has signed
*any particular transaction*.  This is far weaker than the promise
of trusted hardware, where you could have a guarantee that as long as
the protocol hasn't been violated, the user has authorized a *particular*
transaction.  This may be acceptable for authenticating access to
an online retail banking web site, or corporate information, but it
would not be sufficient for an actual payment system (DBS, account
based, or other).

Always interested in learning something new which would chance my assumptions,
Ryan
rdl@mit.edu

On Sun, Sep 20, 1998 at 06:45:06PM +0200, Lucky Green wrote:
| On Sat, 19 Sep 1998, Ryan Lackey wrote:
| 
| > 
| > [from a discussion of tamper-resistant hardware for payment systems
| > on dbs@philodox.com, a mailing list dedicated to digital bearer systems,

| o ArcotSignTM technology is a breakthrough that offers smart card tamper
| resistance in software. Arcot is unique in this regard, and WebFort is the
| only software-only web access control solution on the market that offers
| smart card security, with software convenience and cost. [We have now
| entered deep snake oil territory. Claims that software affords tamper
| resistance comparable to hardware tokens are either based in dishonesty or 
| levels of incompetence in league with "just as secure pseudo-ontime
| pads"].
| 
| In summary, based on the technical information provided by Arcot System,
| the product is a software based authentication system using software based
| client certificates.

	I have no knowledge of Arcot's systems and can't comment on
them.  Hoever, there are ways to make software hard o disassmeble
and/or tamper with.  Given that Arcot is probably going to attack
smartcards as being easily attacked, 'smartcard level' security is not 
that high a target, the claim may not be so outlandish.

	Be intestesting to see how fast the code is.  If they're
embedding certs in complex code that needs to run to sign, then theft
of the cert may be difficult.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

On Sat, 19 Sep 1998, Ryan Lackey wrote:

> 
> [from a discussion of tamper-resistant hardware for payment systems
> on dbs@philodox.com, a mailing list dedicated to digital bearer systems,
> where Scott Loftesness, of DigiCash and Arcot Systems, mentioned ArcotSign.]
> 
> You mentioned the URL for Arcot, and I looked at the site.  It seems
> rather lacking in technical details, and makes a very strong claim --
> that it can provide tamper resistance in software on a hardware/OS/etc.
> platform which is generally hostile (a general purpose computer).

>From the technical description of Arcot's WebFort technology at 
http://www.arcot.com/WebFort1.htm, the product sets up an encrypted and
authenticated channel between the client and the server. You could use
standard SSL with client certs to achieve the same result.

What concerns me are the other outrageous claims made on the site:

o Conventional software solutions offering public key authentication, such
as those from Microsoft, Netscape, and Entrust are no stronger than
username/password mechanisms. [False. UID/PW's are subject to guessing.
Client certs are not].

o ArcotCard is a tamper resistant software only private key storage
system. [Anybody using the words "tamper resitant" to describe a software
based solution is incompetent at best].

o ArcotSignTM technology is a breakthrough that offers smart card tamper
resistance in software. Arcot is unique in this regard, and WebFort is the
only software-only web access control solution on the market that offers
smart card security, with software convenience and cost. [We have now
entered deep snake oil territory. Claims that software affords tamper
resistance comparable to hardware tokens are either based in dishonesty or 
levels of incompetence in league with "just as secure pseudo-ontime
pads"].

In summary, based on the technical information provided by Arcot System,
the product is a software based authentication system using software based
client certificates.

-- Lucky Green <shamrock@cypherpunks.to> PGP v5 encrypted email preferred.

At 06:27 AM 9/21/98 -0400, Adam Shostack wrote:
>On Sun, Sep 20, 1998 at 06:45:06PM +0200, Lucky Green wrote:
>| On Sat, 19 Sep 1998, Ryan Lackey wrote:
>| 
>| > 
>| > [from a discussion of tamper-resistant hardware for payment systems
>| > on dbs@philodox.com, a mailing list dedicated to digital bearer systems,
>
>| o ArcotSignTM technology is a breakthrough that offers smart card tamper
>| resistance in software. Arcot is unique in this regard, and WebFort is the
>| only software-only web access control solution on the market that offers
>| smart card security, with software convenience and cost. [We have now
>| entered deep snake oil territory. Claims that software affords tamper
>| resistance comparable to hardware tokens are either based in dishonesty or 
>| levels of incompetence in league with "just as secure pseudo-ontime
>| pads"].
>| 
>| In summary, based on the technical information provided by Arcot System,
>| the product is a software based authentication system using software based
>| client certificates.
>
>	I have no knowledge of Arcot's systems and can't comment on
>them.  Hoever, there are ways to make software hard o disassmeble
>and/or tamper with.  Given that Arcot is probably going to attack
>smartcards as being easily attacked, 'smartcard level' security is not 
>that high a target, the claim may not be so outlandish.

They're not looking to do tamperproof software.  Their business model can
be best described as: "better than passwords, cheaper than SecurID."

Here's the basic idea:  Strew a million passwords on your hard drive, and
make it impossible to verify which is the correct one offline.  So, someone
who steals the password file off the client cannot run a cracking tool
against the file.

>	Be intestesting to see how fast the code is.  If they're
>embedding certs in complex code that needs to run to sign, then theft
>of the cert may be difficult.

It isn't bad.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Hey Bruce,
doesn't this response of yours imply that the OS is what is comprimised?,
that either the access models and control of the File System on the target
system (that is the one with the million PW's strewn about the disk file
system) is setup wrong or is just not functional. Otherwise why would I want
to take up critical disk space with a management process that had to manage
a million disk-based entities.

Oh and BTW - a simple runtime profiler (i.e. most of the runtime debuggers
will suffice if they have trace capability) will crack which password is the
right one, and I don't even need physical access to the machine to run it in
Microsoft Land. Now if they used the CertCo model and split the key/pw into
several sections and signed or encrypted them separately so that essentially
you have a holographic PW its harder, but the Runtime Profiler is still
capable of creating havoc in this model, I think.

That is exactly the point why SW alone solutions cannot provide the levels
of trust that some forms of commerce require. If the OS is untrustworthy and
you have to replicate the components of the system to confuse an intruder as
to which is the "active entitiy"... then whats to stop the same person from
building a sleeper or coopting the User Memory Space. It seems to me that
this effort will just stop people that are cruising through others
filespaces in search of gold.

As far as commercial trust models are concerned this solution, IMHO, is less
than desirable and in some instances covers up but does not fix, various
liability models for a complete system.

It seems to me (standard disclaimers apply here), that in the real world,
the best way to operate is to trust no one,  not your OS, not your ISP, and
especially not your own people. What that mandates is that there is some
"anchor process" that binds both policy and the systems that implement it to
the firmament. I believe that this is the key to making tools like CDSA and
others (OpSec) more functional. Besides, Imagine the strength of an audit
process based upon one of these immutable policy anchors.

Todd


> -----Original Message-----
> From: dbs@philodox.com [mailto:dbs@philodox.com]On Behalf Of Bruce
> Schneier
> Sent: Monday, September 21, 1998 3:27 AM
> To: Adam Shostack; Lucky Green; Ryan Lackey
> Cc: scott@loftesness.com; dbs@philodox.com; coderpunks@toad.com;
> cryptography@c2.net; cypherpunks@algebra.com
> Subject: Re: ArcotSign (was Re: Does security depend on hardware?)
>
>
> At 06:27 AM 9/21/98 -0400, Adam Shostack wrote:
> >On Sun, Sep 20, 1998 at 06:45:06PM +0200, Lucky Green wrote:
> >| On Sat, 19 Sep 1998, Ryan Lackey wrote:
> >|
> >| >
> >| > [from a discussion of tamper-resistant hardware for payment systems
> >| > on dbs@philodox.com, a mailing list dedicated to digital
> bearer systems,
> >
> >| o ArcotSignTM technology is a breakthrough that offers smart
> card tamper
> >| resistance in software. Arcot is unique in this regard, and
> WebFort is the
> >| only software-only web access control solution on the market
> that offers
> >| smart card security, with software convenience and cost. [We have now
> >| entered deep snake oil territory. Claims that software affords tamper
> >| resistance comparable to hardware tokens are either based in
> dishonesty or
> >| levels of incompetence in league with "just as secure pseudo-ontime
> >| pads"].
> >|
> >| In summary, based on the technical information provided by
> Arcot System,
> >| the product is a software based authentication system using
> software based
> >| client certificates.
> >
> >	I have no knowledge of Arcot's systems and can't comment on
> >them.  Hoever, there are ways to make software hard o disassmeble
> >and/or tamper with.  Given that Arcot is probably going to attack
> >smartcards as being easily attacked, 'smartcard level' security is not
> >that high a target, the claim may not be so outlandish.
>
> They're not looking to do tamperproof software.  Their business model can
> be best described as: "better than passwords, cheaper than SecurID."
>
> Here's the basic idea:  Strew a million passwords on your hard drive, and
> make it impossible to verify which is the correct one offline.
> So, someone
> who steals the password file off the client cannot run a cracking tool
> against the file.
>
> >	Be intestesting to see how fast the code is.  If they're
> >embedding certs in complex code that needs to run to sign, then theft
> >of the cert may be difficult.
>
> It isn't bad.
>
> Bruce
> **********************************************************************
> Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
> 101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
>            Free crypto newsletter.  See:  http://www.counterpane.com
>
>
>

At 08:43 AM 9/21/98 -0700, Todd S. Glassey wrote:
>Hey Bruce,
>doesn't this response of yours imply that the OS is what is comprimised?,
>that either the access models and control of the File System on the target
>system (that is the one with the million PW's strewn about the disk file
>system) is setup wrong or is just not functional. Otherwise why would I want
>to take up critical disk space with a management process that had to manage
>a million disk-based entities.

It's not that much disk space.  The million entries was a methphor.  They use
mathematics instead of raw disk storage.

>Oh and BTW - a simple runtime profiler (i.e. most of the runtime debuggers
>will suffice if they have trace capability) will crack which password is the
>right one, and I don't even need physical access to the machine to run it in
>Microsoft Land. Now if they used the CertCo model and split the key/pw into
>several sections and signed or encrypted them separately so that essentially
>you have a holographic PW its harder, but the Runtime Profiler is still
>capable of creating havoc in this model, I think.

Of course.  It's less secure than hardware solutions.

>That is exactly the point why SW alone solutions cannot provide the levels
>of trust that some forms of commerce require. If the OS is untrustworthy and
>you have to replicate the components of the system to confuse an intruder as
>to which is the "active entitiy"... then whats to stop the same person from
>building a sleeper or coopting the User Memory Space. It seems to me that
>this effort will just stop people that are cruising through others
>filespaces in search of gold.

Agreed.  Think of AOL as the ideal user for this idea.  They want something
a little more secure than passwords, but don't want to spend the money on
hardware.  Passwords can be guessed, or sniffed.  This system doesn't
allow passwords to be guessed, and there are some more additions to 
prevent sniffing (all pretty standard).  Sure, if the client machine is
compromised (installing a sniffer, etc), there is no security, but that's not
the real threat.

>As far as commercial trust models are concerned this solution, IMHO, is less
>than desirable and in some instances covers up but does not fix, various
>liability models for a complete system.

Sure.  But it's good enough for some things.

>It seems to me (standard disclaimers apply here), that in the real world,
>the best way to operate is to trust no one,  not your OS, not your ISP, and
>especially not your own people. What that mandates is that there is some
>"anchor process" that binds both policy and the systems that implement it to
>the firmament. I believe that this is the key to making tools like CDSA and
>others (OpSec) more functional. Besides, Imagine the strength of an audit
>process based upon one of these immutable policy anchors.

That's not the best way to operate in the real world.  I'd much rather have
friends, get married, and have a fun life than to trust no one.  I'd much
rather
take the occassional hit rather than sit alone in the dark holding a gun.
This
is the real world of ninny net users in chat rooms, this isn't online real
estate.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

On Mon, 21 Sep 1998, Bruce Schneier wrote:

> Here's the basic idea:  Strew a million passwords on your hard drive, and
> make it impossible to verify which is the correct one offline.  So, someone
> who steals the password file off the client cannot run a cracking tool
> against the file.

Is this really patentable? It sounds a *lot* like the original public-key
algorithm (the one involving lots of little 'puzzles')

-Bram

bram wrote:
> 
> On Mon, 21 Sep 1998, Bruce Schneier wrote:
> 
> > Here's the basic idea:  Strew a million passwords on your hard drive, and
> > make it impossible to verify which is the correct one offline.  So, someone
> > who steals the password file off the client cannot run a cracking tool
> > against the file.
> 
> Is this really patentable? It sounds a *lot* like the original public-key
> algorithm (the one involving lots of little 'puzzles')

A question : How does the legitimate user find his password?
(Sorry for not having followed this thread from the beginning.)

M. K. Shen

At 08:59 AM 9/22/98 +0100, Mok-Kong Shen wrote:
>bram wrote:
>> 
>> On Mon, 21 Sep 1998, Bruce Schneier wrote:
>> 
>> > Here's the basic idea:  Strew a million passwords on your hard drive, and
>> > make it impossible to verify which is the correct one offline.  So,
someone
>> > who steals the password file off the client cannot run a cracking tool
>> > against the file.
>> 
>> Is this really patentable? It sounds a *lot* like the original public-key
>> algorithm (the one involving lots of little 'puzzles')
>
>A question : How does the legitimate user find his password?
>(Sorry for not having followed this thread from the beginning.)

He uses a remembered secret and some mathematical magic.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

What is password salting ?

About the 64 bit key ....
  example I used the key uvietf31 does this mean it is converted to a 64
   bit 0's or/and 1's?


Thanks!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's me Bernie.
metaphone@altavista.net

Bruce Schneier wrote:
> 
> At 08:59 AM 9/22/98 +0100, Mok-Kong Shen wrote:

> >A question : How does the legitimate user find his password?
> >(Sorry for not having followed this thread from the beginning.)
> 
> He uses a remembered secret and some mathematical magic.

Another naive question: Why is the remembered secret not sufficient
(thus doing away with the magic)?

M. K. Shen

At 12:48 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> At 08:59 AM 9/22/98 +0100, Mok-Kong Shen wrote:
>
>> >A question : How does the legitimate user find his password?
>> >(Sorry for not having followed this thread from the beginning.)
>> 
>> He uses a remembered secret and some mathematical magic.
>
>Another naive question: Why is the remembered secret not sufficient
>(thus doing away with the magic)?

One of the significant improvements is that the scheme is immune to
offline password guessing attacks.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Bruce Schneier wrote:
> 
> At 12:48 PM 9/22/98 +0100, Mok-Kong Shen wrote:
> >Bruce Schneier wrote:

> >> He uses a remembered secret and some mathematical magic.
> >
> >Another naive question: Why is the remembered secret not sufficient
> >(thus doing away with the magic)?
> 
> One of the significant improvements is that the scheme is immune to
> offline password guessing attacks.

If the 'mathematical magic' is not to be kept secret (as in principle
shouldn't for all crypto algorithms) then presumably one could
attack through brute forcing the 'remembered secrect', I guess.
(I suppose the 'remembered secret' has less bits then the 'password'
that is to be retrieved from the pool of millions with the
'mathematical magic'). So the advantages of the scheme appear to
remain unclear as a matter of principle.

M. K. Shen

At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> At 12:48 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>> >Bruce Schneier wrote:
>
>> >> He uses a remembered secret and some mathematical magic.
>> >
>> >Another naive question: Why is the remembered secret not sufficient
>> >(thus doing away with the magic)?
>> 
>> One of the significant improvements is that the scheme is immune to
>> offline password guessing attacks.
>
>If the 'mathematical magic' is not to be kept secret (as in principle
>shouldn't for all crypto algorithms) then presumably one could
>attack through brute forcing the 'remembered secrect', I guess.

Yes, but only through an on-line protocol.   And if the server has some
kind of "turn the user off after ten bad password guesses," then the
atack doesn't work.

>(I suppose the 'remembered secret' has less bits then the 'password'
>that is to be retrieved from the pool of millions with the
>'mathematical magic'). So the advantages of the scheme appear to
>remain unclear as a matter of principle.

The advantages are that offline password guessing is impossible.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Bruce Schneier wrote:
> 
> At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:

> >If the 'mathematical magic' is not to be kept secret (as in principle
> >shouldn't for all crypto algorithms) then presumably one could
> >attack through brute forcing the 'remembered secrect', I guess.
> 
> Yes, but only through an on-line protocol.   And if the server has some
> kind of "turn the user off after ten bad password guesses," then the
> atack doesn't work.

I remember someone wrote of the case where the attacker got the
file with the millions of passwords. Then if he also knows the
'mathematical magic' he could presumably do offline work. So I
suppose that the 'mathematical magic' has to be kept secret, which 
would work against the generally accepted crypto principles.

M. K. Shen

At 7:39 AM -0500 9/22/98, Bruce Schneier wrote:
>At 02:28 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>>Bruce Schneier wrote:
>>>
>>> At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>>
>>> >If the 'mathematical magic' is not to be kept secret (as in principle
>>> >shouldn't for all crypto algorithms) then presumably one could
>>> >attack through brute forcing the 'remembered secrect', I guess.
>>>
>>> Yes, but only through an on-line protocol.   And if the server has some
>>> kind of "turn the user off after ten bad password guesses," then the
>>> atack doesn't work.
>>
>>I remember someone wrote of the case where the attacker got the
>>file with the millions of passwords. Then if he also knows the
>>'mathematical magic' he could presumably do offline work. So I
>>suppose that the 'mathematical magic' has to be kept secret, which
>>would work against the generally accepted crypto principles.
>
>No.  The online protocol can be public.  Nothing has to be kept secret
>in order for this to work.  That would be stupid; we all know that.

	Also, that things are kept secret/unpublished NOW doesn't mean that
they won't be released when the product ships.

	Not knowing anything about this company, they may have seen a novel
way to put existing tools/methods together, and are doing Q/A, interface,
and marketing work, and don't want to publicize their methods _yet_ because
they COULD be beat to market by a product that has less
documentation/Testing/etc.

	If they seem willing to release the algorythm, and essential parts
of the source code, they might have at least a bit of a clue, if Mr.
Schneier is willing to bet reputation capital on it, I'd be hesitant to cry
"Snake oil". At least the first time.

--
petro@playboy.com----for work related issues. I don't speak for Playboy.
petro@bounty.org-----for everthing else.      They wouldn't like that.
                                              They REALLY
Economic speech IS political speech.          wouldn't like that.

At 02:28 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>
>> >If the 'mathematical magic' is not to be kept secret (as in principle
>> >shouldn't for all crypto algorithms) then presumably one could
>> >attack through brute forcing the 'remembered secrect', I guess.
>> 
>> Yes, but only through an on-line protocol.   And if the server has some
>> kind of "turn the user off after ten bad password guesses," then the
>> atack doesn't work.
>
>I remember someone wrote of the case where the attacker got the
>file with the millions of passwords. Then if he also knows the
>'mathematical magic' he could presumably do offline work. So I
>suppose that the 'mathematical magic' has to be kept secret, which 
>would work against the generally accepted crypto principles.

No.  The online protocol can be public.  Nothing has to be kept secret
in order for this to work.  That would be stupid; we all know that.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Bruce Schneier wrote:
> 
> At 02:28 PM 9/22/98 +0100, Mok-Kong Shen wrote:
> >Bruce Schneier wrote:
> >>
> >> At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:
> >
> >> >If the 'mathematical magic' is not to be kept secret (as in principle
> >> >shouldn't for all crypto algorithms) then presumably one could
> >> >attack through brute forcing the 'remembered secrect', I guess.
> >>
> >> Yes, but only through an on-line protocol.   And if the server has some
> >> kind of "turn the user off after ten bad password guesses," then the
> >> atack doesn't work.
> >
> >I remember someone wrote of the case where the attacker got the
> >file with the millions of passwords. Then if he also knows the
> >'mathematical magic' he could presumably do offline work. So I
> >suppose that the 'mathematical magic' has to be kept secret, which
> >would work against the generally accepted crypto principles.
> 
> No.  The online protocol can be public.  Nothing has to be kept secret
> in order for this to work.  That would be stupid; we all know that.

I suppose you misunderstood me. I mean the 'mathematical magic'
cannot be made public. (Or is 'online protocol' = 'mathematical magic'?)
If the 'magic' is public then the attacker with the pool of passwords
could brute force offline.

M. K. Shen

At 02:47 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> At 02:28 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>> >Bruce Schneier wrote:
>> >>
>> >> At 02:20 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>> >
>> >> >If the 'mathematical magic' is not to be kept secret (as in principle
>> >> >shouldn't for all crypto algorithms) then presumably one could
>> >> >attack through brute forcing the 'remembered secrect', I guess.
>> >>
>> >> Yes, but only through an on-line protocol.   And if the server has some
>> >> kind of "turn the user off after ten bad password guesses," then the
>> >> atack doesn't work.
>> >
>> >I remember someone wrote of the case where the attacker got the
>> >file with the millions of passwords. Then if he also knows the
>> >'mathematical magic' he could presumably do offline work. So I
>> >suppose that the 'mathematical magic' has to be kept secret, which
>> >would work against the generally accepted crypto principles.
>> 
>> No.  The online protocol can be public.  Nothing has to be kept secret
>> in order for this to work.  That would be stupid; we all know that.
>
>I suppose you misunderstood me. I mean the 'mathematical magic'
>cannot be made public. (Or is 'online protocol' = 'mathematical magic'?)
>If the 'magic' is public then the attacker with the pool of passwords
>could brute force offline.

No.  You misunderstood me.  There is NOTHING secret except the key.
The online protocol, mathematical magic, source code, algorithm details,
and everything else can be made public.  There are no secrets in the
system except for the keys.

Yes, it's not obvious how you do this.  That's why Arcot is turning this
into a product--it's a good idea.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Bruce Schneier wrote:
> 
> >I suppose you misunderstood me. I mean the 'mathematical magic'
> >cannot be made public. (Or is 'online protocol' = 'mathematical magic'?)
> >If the 'magic' is public then the attacker with the pool of passwords
> >could brute force offline.
> 
> No.  You misunderstood me.  There is NOTHING secret except the key.
> The online protocol, mathematical magic, source code, algorithm details,
> and everything else can be made public.  There are no secrets in the
> system except for the keys.

In that case please allow me to go back to a point raised by me
previously. The user uses his 'remembered secret' (of fewer bits) 
through a public algorithm (including protocol) to retrieve from a 
pool the password (of more bits). If the attacker doesn't have the 
pool then everything looks fine. But if he manages to get the pool
(a case someone mentioned in this thread) then he can obviously
brute force offline, I believe, since he possesses now everything
the legitimate user has, excepting the 'remembered secret'. Or is
there anything wrong with my logic?

M. K. Shen

Bruce Schneier wrote:
> >(I suppose the 'remembered secret' has less bits then the 'password'
> >that is to be retrieved from the pool of millions with the
> >'mathematical magic'). So the advantages of the scheme appear to
> >remain unclear as a matter of principle.
> 
> The advantages are that offline password guessing is impossible.

The 'I' word always makes me nervous - do you really mean that, or do
you just mean "very difficult"?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/

WE'RE RECRUITING! http://www.aldigital.co.uk/

At 03:04 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> >I suppose you misunderstood me. I mean the 'mathematical magic'
>> >cannot be made public. (Or is 'online protocol' = 'mathematical magic'?)
>> >If the 'magic' is public then the attacker with the pool of passwords
>> >could brute force offline.
>> 
>> No.  You misunderstood me.  There is NOTHING secret except the key.
>> The online protocol, mathematical magic, source code, algorithm details,
>> and everything else can be made public.  There are no secrets in the
>> system except for the keys.
>
>In that case please allow me to go back to a point raised by me
>previously. The user uses his 'remembered secret' (of fewer bits) 
>through a public algorithm (including protocol) to retrieve from a 
>pool the password (of more bits). If the attacker doesn't have the 
>pool then everything looks fine. But if he manages to get the pool
>(a case someone mentioned in this thread) then he can obviously
>brute force offline, I believe, since he possesses now everything
>the legitimate user has, excepting the 'remembered secret'. Or is
>there anything wrong with my logic?

Yes.  There is something wrong with you logic.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

> >the legitimate user has, excepting the 'remembered secret'. Or is
> >there anything wrong with my logic?
> 
> Yes.  There is something wrong with you logic.
> 
> Bruce
> **********************************************************************
> Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098

There's something wrong with you grammer.

Cheers,
Julian.

At 03:40 AM 9/23/98 +1000, proff@iq.org wrote:
>> >the legitimate user has, excepting the 'remembered secret'. Or is
>> >there anything wrong with my logic?
>> 
>> Yes.  There is something wrong with you logic.
>> 
>> Bruce
>> **********************************************************************
>> Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
>
>There's something wrong with you grammer.

Touche.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

At 03:24 PM 9/22/98 +0100, Ben Laurie wrote:
>Bruce Schneier wrote:
>> >(I suppose the 'remembered secret' has less bits then the 'password'
>> >that is to be retrieved from the pool of millions with the
>> >'mathematical magic'). So the advantages of the scheme appear to
>> >remain unclear as a matter of principle.
>> 
>> The advantages are that offline password guessing is impossible.
>
>The 'I' word always makes me nervous - do you really mean that, or do
>you just mean "very difficult"?

Intractable, actually.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Bruce Schneier wrote:
>> The advantages are that offline password guessing is impossible.

At 03:24 PM 9/22/98 +0100, Ben Laurie wrote:
> The 'I' word always makes me nervous - do you really mean that, or do
> you just mean "very difficult"?

Why be nervous?  It's not that hard to prevent off-line
guessing of the PIN, given access to just the client's stored
data.  Here "impossible" means "as hard as breaking your
favorite PK method".

Here are three ways of authenticating based on PIN + stored key
where the stored client data alone doesn't permit offline PIN
guessing.  These methods are arguably better than using a
simplistic PIN-encrypted private key, if you're concerned
about the client spilling its data.

(1)	Send the PIN separately, encrypted by the server's public key.
	Don't encrypt the private key with the PIN.  Make the server
	verify both PIN and private key to permit a transaction.

(2)	Use the PIN + stored data to derive the private key,
	in a way such that any PIN will also generate a valid
	private key.

(3)	Verify the PIN (or PIN-derived key) using
	password-authenticated key exchange.

Each of these approaches has other benefits and limitations.
>From the posted description, it sounds like Arcot is using (2),
where the PIN-encrypted data contains no verifiable plaintext.

-------------------------
David P. Jablon
dpj@world.std.com
<http://world.std.com/~dpj/>

Bruce Schneier wrote:
> 
> At 03:04 PM 9/22/98 +0100, Mok-Kong Shen wrote:
> >Bruce Schneier wrote:
> >>
> >> >I suppose you misunderstood me. I mean the 'mathematical magic'
> >> >cannot be made public. (Or is 'online protocol' = 'mathematical magic'?)
> >> >If the 'magic' is public then the attacker with the pool of passwords
> >> >could brute force offline.
> >>
> >> No.  You misunderstood me.  There is NOTHING secret except the key.
> >> The online protocol, mathematical magic, source code, algorithm details,
> >> and everything else can be made public.  There are no secrets in the
> >> system except for the keys.
> >
> >In that case please allow me to go back to a point raised by me
> >previously. The user uses his 'remembered secret' (of fewer bits)
> >through a public algorithm (including protocol) to retrieve from a
> >pool the password (of more bits). If the attacker doesn't have the
> >pool then everything looks fine. But if he manages to get the pool
> >(a case someone mentioned in this thread) then he can obviously
> >brute force offline, I believe, since he possesses now everything
> >the legitimate user has, excepting the 'remembered secret'. Or is
> >there anything wrong with my logic?
> 
> Yes.  There is something wrong with you logic.

Please kindly explain. I like very much to learn from my errors.
Thank you very much in advance.

M. K. Shen

Would it be terribly difficult to remove the "coderpunks" list from the
"To:" list on this thread?

Thanks,

Kris

-- 
Kriston J. Rehberg
http://kriston.net/
AOL: Kriston                    endeavor to persevere
ICQ: 3535970

At 11:38 PM -0700 9/22/98, Kriston J. Rehberg wrote:
>Would it be terribly difficult to remove the "coderpunks" list from the
>"To:" list on this thread?
>
>Thanks,


Kris,

Why are you spamming the Cypherpunks list with your drivel?


--Tim May

(This space left blank pending determ. of acceptability to the gov't.)
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   831-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.

David Jablon wrote:
> 
> Bruce Schneier wrote:
> >> The advantages are that offline password guessing is impossible.
> 
> At 03:24 PM 9/22/98 +0100, Ben Laurie wrote:
> > The 'I' word always makes me nervous - do you really mean that, or do
> > you just mean "very difficult"?
> 
> Why be nervous?  It's not that hard to prevent off-line
> guessing of the PIN, given access to just the client's stored
> data.  Here "impossible" means "as hard as breaking your
> favorite PK method".

Which is:

a) not impossible
b) not proven to be as difficult as we think it is (cf. quantum
computers, novel factorisation methods).

That's why.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/

WE'RE RECRUITING! http://www.aldigital.co.uk/

At 07:10 PM 9/22/98 +0100, Mok-Kong Shen wrote:
>Bruce Schneier wrote:
>> 
>> Yes.  There is something wrong with your logic.
>
>Please kindly explain. I like very much to learn from my errors.
>Thank you very much in advance.

Sorry.  I am under NDA.  Hopefully Arcot will explain sooner rather than
later.
I suggest not using the product until you are satisfied.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

On Wed, 23 Sep 1998, Bruce Schneier wrote:

> Sorry.  I am under NDA.  Hopefully Arcot will explain sooner rather than
> later. I suggest not using the product until you are satisfied.

I'd say the following has been well established by now - 

- The people at ArcotSign are not completely clueless

- They're doing things in a possibly sub-optimal way as far as publically
explaining their algorithms, but this is a decision on their part, it's
not that they don't have reasonable algorithms to back things up

- They're not releasing due to being afraid of people copying their
product before they've gotten sufficiently far in development/achieved
some market penetration. Those of you who don't work at startups might not
be familiar with this sort of thinking, but it's completely reasonable -
if you go around telling everybody all the little details of how to make
things work, some large company might make a very quick bastardized
version and throw lots of marketing oomph behind it.

- Their marketing materials are a bit misleading. This they can reasonably
be faulted for.

In short, at worst it's a poor product, but not 'snake-oil'. I have no
idea whether it's a *good* product, since I've never looked at it, but for
all I know it might be the greatest thing since sliced bread.

I think that pretty much sums up everything there is to currently say on
the subject, until ArcotSign releases more details.

-Bram

(Who isn't talking about what he's working on until the official release
of a reasonably well fleshed-out product comes out.)

At 01:32 PM 9/21/98 -0700, bram wrote:
>On Mon, 21 Sep 1998, Bruce Schneier wrote:
>
>> Here's the basic idea:  Strew a million passwords on your hard drive, and
>> make it impossible to verify which is the correct one offline.  So, someone
>> who steals the password file off the client cannot run a cracking tool
>> against the file.
>
>Is this really patentable? It sounds a *lot* like the original public-key
>algorithm (the one involving lots of little 'puzzles')

I am not an attorney, so I cannot advise on patentability.  But note that
I simplified the explanation A LOT in the above paragraph.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

In response to the interest indicated by the discussion on coderpunks/cipherpunks
mailing lists, we have put a technical note about the Arcot key container
("software smart card") on our site at:

        http://www.arcot.com/camo2.html

We would appreciate your comments.

This note doesn't tell everything about our method--we *are* developing a
commercial product, after all--but we hope that it will suffice to show
knowledgeable readers our main ideas and convince them that a software key
container that provides protection similar to that of a smart card is in fact
possible.

I should remark that:

- Arcot key protection does not depend on making client-side
  software complicated or on keeping the algorithms secret.  It
  depends on making it hard for an attacker to tell when he has
  cracked it, by keeping information that the attacker might use
  to identify the private key out of his reach (such as the
  public key).

- Consequently, there are significant restrictions on the
  situations in which Arcot key protection works.  For example:

  - It isn't useful for encryption.
  - It isn't good for stranger-to-stranger authentication.
  - It is good for authenticating yourself to your bank, an
    online merchant with whom you have an account, or to your
    employer.

- Like smartcards, it provides two-factor authentication--you
  need to have the key container and know the password in order
  to authenticate.  Its key protection is slightly weaker because
  it is easier to steal (just copy) a card without the theft being
  noticed.

- Of course, the crypto has to be done in software.  If your
  application warrants that level of paranoia, then maybe you
  really should be using hardware--but are you sure that your
  smart card is really signing the document you think it
  is?   Most commercial applications don't warrant this level
  of paranoia.  And hardware costs money.


Regards,

Doug Hoover



begin:          vcard
fn:             Douglas Hoover
n:              Hoover;Douglas
org:            Arcot Systems
adr:            2197 Bayshore Rd;;;Palo Alto;CA;94303;US
email;internet: doug@arcot.com
tel;work:       650 470-8203
tel;fax:        650 470-8208
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard