Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[David Alexander Molnar]

On Thu, 20 Oct 2005, cyphrpunk wrote:


system without excessive complications. Only the fifth point, the
ability for outsiders to monitor the amount of cash in circulation, is
not satisfied. But even then, the ecash mint software, and procedures
and controls followed by the issuer, could be designed to allow third
party audits similarly to how paper money cash issuers might be
audited today.


One approach, investigated by Hal Finney, is to run the mint on a platform 
that allows remote attestation. Check out rpow.net - he has a working 
implementation of a proof of work payment system hosted on an IBM 4758.


-David Molnar

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Cisco VPN password recovery program

[Florian Weimer]

> http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_guide_chapter09186a00803ee1f0.html#wp2477015
>
> - - -
>
> Cisco Client Parameters
>
> Allow Password Storage on Client - Check this box to allow IPSec
> clients to store their login passwords on their local client
> systems. If you do not allow password storage (the default), IPSec
> users must enter their password each time they seek access to the
> VPN. For maximum security, we recommend that you not allow password
> storage.
>
> - - -

I really doubt that this affects group password (PSK).

In some cases, network administrators used the password obfuscation to
force their users to use Cisco's VPN client.  Competing products, such
as vpnc, do not enforce client-side policies.  However, there's been a
website where you can upload the obfuscated password, and it returns
the password in clear text for quite some time now.  It is implemented
by running the Cisco client under a debugging tool, intercepting a
memcpy call that copies the password.

In the end, the publication of the algorithm doesn't change the
security of the system (there wasn't much to start with).  But it's
certainly easier to write interoperable software using this
information.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Cisco VPN password recovery program

[Florian Weimer]

* Perry E. Metzger:

> Via cryptome:
>
> http://evilscientists.de/blog/?page_id=343
>
>The Cisco VPN Client uses weak encryption to store user and group
>passwords in your local profile file.  I coded a little tool to
>reveal the saved passwords from a given profile file.
>
> If this is true, it doesn't sound like Cisco used a particularly smart
> design for this.

Why?  In essence, this is the PSK that is used to authenticate the VPN
gateway.  It must be available in cleartext on the client.

(Later versions offer asymmetric encryption as well.)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [Clips] Read two biometrics, get worse results - how it works

[[EMAIL PROTECTED]]

On 10/19/05, R.A. Hettinga <[EMAIL PROTECTED]> wrote:
>
>  [EDIT]
>  Daugman presents
>  (http://www.cl.cam.ac.uk/users/jgd1000/combine/combine.html) the two rival
>  intuitions, then does the maths. On the one hand, a combination of
>  different tests should improve performance, because more information is
>  better than less information. But on the other, the combination of a strong
>  test with a weak test to an extent averages the result, so the result
>  should be less reliable than if one were relying solely on the strong test.
>
I believe the Daugman results are correct only when one accepts
results where the tests disagree. That is, if the first test returns
positive and the second test returns negative, you chose the overall
results to be positive or negative as opposed to "do over until they
agree".

Of course, in real life with knowledge of the physics of the tests and
the ability to pull out non-boolean results, one may be able to remove
many of the "do over" results to keep from annoying the test subjects.

-Michael Heyman

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

Let's take a look at Daniel Nagy's list of desirable features for an
ecash system and see how simple, on-line Chaum ecash fares.

>  http://www.epointsystem.org/~nagydani/ICETE2005.pdf
>
>  One of the reasons, in the author s opinion, is that payment systems
>  based on similar schemes lack some key characteristics of paper-based
>  cash, rendering them economically infeasible. Let us quickly enumerate
>  the most important properties of cash:
>
>  1.  "Money doesn't smell."  Cash payments are -- potentially --
>  _anonymous_ and untraceable by third parties (including the issuer).

This is of course the main selling point of Chaum's system, where it
excels. I will point out that defining cash as merely "potentially"
anonymous leaves a loophole whereby fully non-anonymous systems get to
call themselves cash. This underplays the strength of Chaum's system.
It is not just "potentially" anonymous, it has a strong degree of
anonymity.

>  2. Cash payments are final. After the fact, the paying party has no
>  means to reverse the payment. We call this property of cash
>  transactions _irreversibility_.

Certainly Chaum ecash has this property. Because deposits are
unlinkable to withdrawals, there is no way even in principle to
reverse a transaction.

>  3. Cash payments are _peer-to-peer_. There is no distinction between
>  merchants and customers; anyone can pay anyone. In particular, anybody
>  can receive cash payments without contracts with third parties.

Again this is precisely how Chaum ecash works. Everyone can receive
ecash and everyone can spend it. There is no distinction between
buyers and vendors. Of course, transactions do need the aid of the
issuer, but that is true of all online payment systems including
Daniel's.

>  4. Cash allows for "acts of faith" or _naive transactions_. Those who
>  are not familiar with all the antiforgery measures of a particular
>  banknote or do not have the necessary equipment to verify them, can
>  still transact with cash relying on the fact that what they do not
>  verify is nonetheless verifiable in principle.

I have to admit, I don't understand this point, so I can't say to what
extent Chaum ecash meets it. In most cases users will simply use their
software to perform transactions and no familiarity is necessary with
any antiforgery or other technical measures in the payment system. In
this sense all users are "naive" and no one is expected to be a
technical expert. Chaum ecash works just fine in this model.

>  5. The amount of cash issued by the issuing authority is public
>  information that can be verified through an auditing process.

This is the one aspect where Chaum ecash fails. It is a significant
strength of Daniel Nagy's system that it allows public audits of the
amount of cash outstanding.

However note that if the ecash issuer stands ready to buy and sell
ecash for "real money" then he has an incentive not to excessively
inflate his currency as it would create liabilities which exceed his
assets. Similarly, in a state of competition between multiple such
ecash issuers, any currency which over-inflates will be at a
disadvantage relative to others, as discussed in Dan Selgin's works on
"free banking".

Daniel Nagy also raised a related point about insider malfeasance,
which is also a potential problem with Chaum ecash, but there do exist
technologies such as hardware security modules which can protect keys
in a highly secure manner and make sure they are used only via
authorized protocols. Again, the operators of the ecash system have
strong incentives to protect their keys against insider attacks.

>  The payment system proposed in (D. Chaum, 1988) focuses on the first
>  characteristic while partially or totally lacking all the others.

In summary, I don't think this is true at all. At least the first
three characteristics are met perfectly by Chaumian ecash, and
possibly the fourth is met in practice as naive users can access the
system without excessive complications. Only the fifth point, the
ability for outsiders to monitor the amount of cash in circulation, is
not satisfied. But even then, the ecash mint software, and procedures
and controls followed by the issuer, could be designed to allow third
party audits similarly to how paper money cash issuers might be
audited today.

There do exist technical proposals for ecash systems such as that from
Sander and Ta-Shma which allow monitoring the amount of cash which has
been issued and redeemed while retaining anonymity and unlinkability,
but those are of questionable efficiency with current technology.
Perhaps improved versions of such protocols could provide a payment
system which would satisfy all of Daniel Nagy's desiderata while
retaining the important feature of strong anonymity.

CP

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [Clips] Read two biometrics, get worse results - how it works

[dan]

RAH, et al.,

It is true that one can combine two diagnostic
tests to a worse effect than either alone, but
it is not a foredrawn conclusion.  To take a
medical example, you screen first with a cheap
test that has low/no false negatives then for the
remaining positives you screen with a potentially
more expensive test that has low/no false positives.
There is a whole health policy & management
literature on this.  I reproduce the barest
precis of same below, assuming the reader can
manage to view it in a fixed width font while
respecting my hard carriage returns as writ.

--dan



  cheat sheet on terminology of medical diagnostic testing
_

  \  the true situation
   \
\+   -
 +---+---+---
 |   |   |
   + |   a   |   b   |  a+b
what the |   |   |
diagnostic   +---+---+---
test returns |   |   |
   - |   c   |   d   |  c+d
 |   |   |
 +---+---+---
 |   |   |
 |  a+c  |  b+d  |   t

   true positives
  a = positive testers who have disease

   true negatives
  d = negative testers who are without disease

   false positives
  b = positive testers who are without disease

   false negatives
  c = negative testers who have disease

   prevalence
  (a+c)/t = fraction of population that has disease

   sensitivity
  a/(a+c) = what fraction of those with disease test positive

   specificity
  d/(b+d) = what fraction of those without disease test negative

   predictive value positive
  a/(a+b) = what fraction of positive tests have disease

   predictive value negative
  a/(a+b) = what fraction of negative tests are without disease

   Notes:

   Information retrieval people know sensitivity as "recall" and
   predictive value positive as "precision."

   Screening with a cheap test with high sensitivity then an expensive
   test with high specificity is often the best (most cost effective)
   strategy.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Practical Security Mailing List

[Hagai Bar-El]

Hello,

I would like to notify you all of a new mailing list forum which I 
opened. It is called "Practical Security" and is aimed at discussing 
security measures in the context of real problems in real projects. 
It has a much narrower scope than the Cryptography mailing list and 
by no means intends to replace it or to compete with it.


From the mailing list info page:

This forum discusses applications of cryptographic protocols as well 
as other security techniques, such as (but not limited to) methods 
for authentication, data protection, reverse-engineering protection, 
denial-of-service protection, and digital rights management. The 
forum also discusses implementation pitfalls to avoid. This forum 
does not discuss theoretical and/or mathematical aspects of 
cryptography. Neither does the forum discuss particular 
vulnerabilities of commercial products, such as what one may find in BugTraq.
Joining this mailing list is especially recommended to professionals 
who design security systems and to application designers who are also 
responsible for the security aspects of their products.


I confess that at the moment of writing the list has just a few 
participants, but I project that it will grow much larger.


To subscribe visit http://www.hbarel.com/practicalsecurity or send a 
blank message to [EMAIL PROTECTED]


Regards,
Hagai.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

[Clips] Read two biometrics, get worse results - how it works

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Wed, 19 Oct 2005 23:32:55 -0400
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] Read two biometrics, get worse results - how it works
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]

 

 The Register

 Biting the hand that feeds IT
 The Register » Internet and Law » Digital Rights/Digital Wrongs »

 Original URL:
http://www.theregister.co.uk/2005/10/19/daugman_multi_biometrics/
 Read two biometrics, get worse results - how it works
 By John Lettice (john.lettice at theregister.co.uk)
 Published Wednesday 19th October 2005 14:47 GMT

 A regular correspondent (thanks, you know who you are) points us to some
 calculations by John Daugman, originator of the Daugman algorithms for iris
 recognition. These ought to provide disturbing reading for Home Office
 Ministers who casually claim that by using multiple biometrics
 (http://www.theregister.co.uk/2005/10/17/mcnulty_fingers_id_problem/)
 you'll get a better result than by using just the one. Although that may
 seem logical, it turns out that it it isn't, necessarily.

 Daugman presents
 (http://www.cl.cam.ac.uk/users/jgd1000/combine/combine.html) the two rival
 intuitions, then does the maths. On the one hand, a combination of
 different tests should improve performance, because more information is
 better than less information. But on the other, the combination of a strong
 test with a weak test to an extent averages the result, so the result
 should be less reliable than if one were relying solely on the strong test.
 (If Tony McNulty happens to be with us, we suggest he fetches the ice pack
 now.)

 "The key to resolving the apparent paradox," writes Daugman, "is that when
 two tests are combined, one of the resulting error rates (False Accept or
 False Reject rate) becomes better than that of the stronger of the two
 tests, while the other error rate becomes worse even than that of the
 weaker of the tests. If the two biometric tests differ significantly in
 their power, and each operates at its own cross-over point, then combining
 them gives significantly worse performance than relying solely on the
 stronger biometric.

 This is of particular relevance to the Home Office's current case for use
 of multiple biometrics, because its argument is based on the use of three
 types of biometric, fingerprint, facial and iris, which are substantially
 different in power.

 Daugman produces the calculations governing the use of two hypothetical
 biometrics, one with both false accept and false reject rates of one in
 100, and the second with the two rates at one in 1,000. On its own,
 biometric one would produce 2,000 errors in 100,000 tests, while biometric
 two would produce 200. You can treat the use of two biometrics in one of
 two ways - the subject must be required to pass both (the 'AND' rule) or
 the subject need only pass one (the 'OR' rule). Daugman finds that under
 either rule there would be 1,100 errors, i.e. 5.5 times more errors than if
 the stronger test were used alone.

 He concludes that a stronger biometric is therefore better used alone than
 in combination, but only when both are operating at their crossover points.
 If the false accept rate (when using the 'OR' rule) or the false reject
 rate (when using the 'AND' rule) is brought down sufficiently (to "smaller
 than twice the crossover error rate of the stronger test", says Daugman)
 then use of two can improve results. If we recklessly attempt to put a
 non-mathemetical gloss on that, we could think of the subject having to
 pass two tests (in the case of the 'AND') rule of, say, facial and iris.
 Dropping the false reject rate of the facial test (i.e. letting more people
 through) in line with Daugman's calculations would produce a better result
 than using iris alone, but if the facial system rejects fewer people
 wrongly, then it will presumably be accepting more people wrongly.

 Which suggests to us that simply regarding a second or third biometric as a
 fall back to be used only if earlier tests fail constructs a scenario where
 the combined results will be worse than use of the single stronger test,
 because in such cases the primary biometric test would have to be
 sufficiently strong to stand on its own, because you won't always be using
 the second or third test.

 The deployment of biometric testing equipment in the field is also likely
 to have a confusing effect on relative error rates, because environmental
 factors will tend to impact the different tests to different degrees. Poor
 lighting may have an effect on iris and facial but not on fingerprint,
 while the aircon breaking down may produce greasy fingers and puffy red
 faces, but leave iris intact. Which would presumably mess up attempts to
 sync error rates.

 But we feel ourselves beginning to intuit, and had 

[Clips] Bruce Schneier talks cyber law

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Wed, 19 Oct 2005 23:33:54 -0400
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] Bruce Schneier talks cyber law
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]

 

 The Register

 Biting the hand that feeds IT
 The Register » Security » Network Security »

 Original URL: http://www.theregister.co.uk/2005/10/19/schneier_talks_law/
 Bruce Schneier talks cyber law
 By John Oates in Vienna (john.oates at theregister.co.uk)
 Published Wednesday 19th October 2005 10:01 GMT

 RSA Europe 2005 ISPs must be made liable for viruses and other bad network
 traffic, Bruce Schneier, security guru and founder and CTO of Counterpane
 Internet Security, told The Register yesterday.

 He said: "It's about externalities - like a chemical company polluting a
 river - they don't live downstream and they don't care what happens. You
 need regulation to make it bad business for them not to care. You need to
 raise the cost of doing it wrong." Schneier said there was a parallel with
 the success of the environmental movement - protests and court cases made
 it too expensive to keep polluting and made it better business to be
 greener.

 Schneier said ISPs should offer consumers "clean pipe" services: "Corporate
 ISPs do it, why don't they offer it to my Mum? We'd all be safer and it's
 in our interests to pay.

 "This will happen, there's no other possibility."

 He said there was no reason why legislators do such a bad job of drafting
 technology laws. Schneier said short-sighted lobbyists were partly to
 blame. He said much cyber crime legislation was unnecessary because it
 should be covered by existing laws - "theft is theft and trespass is still
 trespass".

 But Schneier conceded that getting international agreements in place would
 be very difficult and that we remain at risk from the country with the
 weakest laws - in the same way we remain at risk from the least
 well-protected computer on the network.
 --
 -
 R. A. Hettinga 
 The Internet Bearer Underwriting Corporation 
 44 Farquhar Street, Boston, MA 02131 USA
 "... however it may deserve respect for its usefulness and antiquity,
 [predicting the end of the world] has not been found agreeable to
 experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]