Re: analysis and implementation of LRW

Steve Schear wrote:
> Here is the situation.  An on-line financial service,
for example a DBC 
> (Digital Bearer Certificate), operator wishes his meat
space identity, 
> physical whereabouts, the transaction servers and at
least some of the 
> location(s) of the service's asset backing to remain
secret.  The 
> service provides frequent, maybe even real-time, data
on its asset 
> backing versus currency in circulation. The operator
wishes to provide 
> some assurance to his clients that the backing and the
amount of 
> currency in circulation are in close agreement.  The
mint's backing need 
> not be in a single location nor in the sole possession
of the operator.


The servers are not so relevant, as long as you have created

legally firm transactions.  Although, in the event of 
collapse, the data trail suddenly becomes of critical 
importance, so there are limits to that.

The reserve assets' location(s) is fairly important from a 
customer trust perspective.  People look at the overall 
safety and make their own judgements.  One person might 
decide that New York is safe and another will find that a 
horrible thought (for those who follow this arcane field, 
there was a big bust of a dodgy operator in NY some months 
back).  Having said that, once a system is up and running, 
and is robust, it seems that moving the assets from one 
continent to another has not been a source of concern to 
many users.

The issuer himself is pretty important.  His physical 
location isn't so important -- everyone flies around these 
days -- but nobody has ever been able to gain trust in a 
system to date without reference to a real meatspace hook. 
And for good reason ... how do you take him to court?  (And

if you are thinking of extra-jurisdictional transactions, 
how do you beat him to a pulp with a baseball bat?)


> I realize this is a governance question but I suspect
that crypto/data 
> security may play a key role.


It does ... but only after the full governance story is put

into place.  Then, we can look at ways to solve certain 
governance problems with crypto.

E.g., Ricardian contracts (my stuff) take the user agreement

as a document and bind it into each transaction by means of

the hash of the contract;  they also ensure various other 
benefits such as the contract being available and readable 
to all at all times, and the acceptability of same, by the 
simple expedient of coding the decimalisation into the 
contract.  Ensuring that the contract is readable, 
applicable and is available to all is a huge win in any 
court case.

Other governance tricks:  the usage of signed receipts can 
be used to construct a full audit of the digital system. 
Also, signed receipts are strong evidence of a transaction,

which leads by some logic to a new regime which we call 
triple entry accounting.  This dramatically changes the 
practice of accounting (which feeds into governance).

With DB side, one trick is to use psuedonym accounts for the

basis, and this allows no-loss protocols to be created. 
Again, this is useful for governance, because if you have a

lossy protocol, you have a potential for fraud.


> Some questions:
> If independent auditors are used do they need to know
the operator's 
> identity?


The essence is the contract.  In a classical online 
financial offering, this contract defaults to the user 
agreement.  This contract offers things to the user, and it

offers it in the name of the Issuer.

If the contract offers nothing, you don't care who the 
Issuers is.  (Some contracts do offer you nothing...)

An Independent Auditor (of a valuable contract) would need 
to know the pedigree of the Issuer.  In evaluating the 
contract that is extended between the issuer and the holders

of value, there needs to be some "meatspace mass"
that says 
that the various clauses in the contract can be met.  E.g.,

If the issuer is totally anonymous and the contract says 
that the issuer will be good for a million of personal 
assets backing then this is a difficult clause to believe
in.


> What aspects of good governance can be brought to bear
on this situation 
> so that the operator's interests are more aligned with
its clients?


Well, one of the things that is normally done is that the 
assets that reserve the contractual promises can be audited

in some fashion.  For the gold people it was commonly 
suggested that cameras be used;  another possibility was to

conduct an audit of reserves from time to time with a person

of known integrity and independence, a different one each 
time, under the cameras.


> Has anyone explored this from a math-crypto view?


It's well explored in Ricardo (my stuff).  The digital side

is capable of being fully and completely audited (not that 
it is, but the signed receipt structure allows it).  5PM and

the balance sheet approach tie the numbers to the contract 
and then across to the physical assets.  5PM can also be 
used to control the physical assets to a lesser extent, but

there we find more need for physical auditing.  It's hard to

go totally digital and cryptographic with a pallet of gold,

unless we're in one of those Neal Stephenson novels.


> If the backing is distributed among a multitude of
holders (e.g., in a 
> fashion similar to how Lloyds backs their insurance
empire), who's 
> identities are kept secret until audit time and then
only a few, 
> randomly selected, names and claimed deposit amounts
are revealed to the 
> auditors, might this statistical sampling and the
totals projected from 
> the results be a reasonable replacement for 'full
asset' audit?  To 
> protect the identities of the holders could a complete
list of the 
> hashes of each name and claimed deposit be revealed to
the auditors, who 
> then select M of N hashes whereupon the operator
reveals only those 
> identities and claimed deposits work
cryptographically?


The Independent Auditor is likely to demand the whole list 
and then to sample and test.  If not, he has to audit your 
formulas, and Auditors don't place much faith in crypto blah

blah as a matter of principle.

With something like physical assets, it is hard to gain long

term trust if you do not identify the location of the assets

to some extent, at least in the early days.  Short term 
trust can be gained, this has been shown empirically, so if

you are operating a transient payment system then that has 
more of a chance of getting away with missing elements of 
governance.  The smaller transactions cycle is completed so

quickly that people know when things aren't working more 
quickly.

Bear also in mind that the classical audit approach is 
designed for a static, snap-shot, long-distance approach. 
This is all topsy turvy these days.  You need to look more 
for open governance, rather than employing auditors, as 
otherwise you're wasting your money.

iang

PS: disclosure, I write these things, and am also a auditing

a non-FC system at the moment.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Ian G wrote:
> E.g., Ricardian contracts (my stuff) take the user
agreement as a 
> document and bind it into each transaction by means of
the hash of the 
> contract;  they also ensure various other benefits such
as the contract 
> being available and readable to all at all times, and
the acceptability 
> of same, by the simple expedient of coding the
decimalisation into the 
> contract.  Ensuring that the contract is readable,
applicable and is 
> available to all is a huge win in any court case.
> 
> Other governance tricks:  the usage of signed receipts
can be used to 
> construct a full audit of the digital system. Also,
signed receipts are 
> strong evidence of a transaction, which leads by some
logic to a new 
> regime which we call triple entry accounting.  This
dramatically changes 
> the practice of accounting (which feeds into
governance).
> 
> With DB side, one trick is to use psuedonym accounts
for the basis, and 
> this allows no-loss protocols to be created. Again,
this is useful for 
> governance, because if you have a lossy protocol, you
have a potential 
> for fraud.

we had done something analogous in the x9.59 financial
standard. the x9a10
financial standard group had been given the requirement to
preserve the
financial infrastructure for all retail payments. 
http://www
.garlic.com/~lynn/x959.html#x959

digital signature on the transaction itself provided for
end-to-end
strong authentication (armoring payment transaction as
countermeasure
to various kinds of replay attacks ... as have been in the
news recently
related to large data breaches and then being able to
subsequently
use the information for fraudulent transactions).

one of the "problems" was that some of the other
attempts at PKI-related
payments protocols in that period ... were creating enormous

(two orders of magnitude) processing and  payload bloat
http
://www.garlic.com/~lynn/subpubkey.html#bloat

one of the implied x9a10 requirements was efficiency, i.e.
mechanism that could be
deployed in ALL environments (internet, point-of-sale,
cellphone, etc) ...
and needed to be highly concerned about processing and
payload efficiency.

the actual transaction is digitally signed ... and it is
also the thing that
is authorized, logged, archived, audited, etc.

so part of x9.59 provided for a hash of the  receipt
(contract,  bill-of-materials, 
sku data, "level 3" data, etc) as part of the
digitally signed payload
(as opposed to including the whole receipt). Then in any
subsequent dispute,
if both parties didn't produce identical receipts ... the
hash from the
audited/logged/archived transaction could be used to
determine the
valid/correct receipt.

While the receipt wasn't part of the actual
audited/archived/logged transaction,
the process provided a mechanism (in cases of disputes) for
establishing the
legitimate receipt.

we claimed privacy agnostic for x9.59 ... i.e. there was an
account number in
protocol but the degree that any jurisdiction required a
binding between an 
account number and an individual was outside the x9.59
protocol. x9.59 was
designed so that it could be used for credit, debit, stored
value, ach, etc.
In many jurisdictions, credit & debit can have some
"know you customer"
requirements for financial institutions (binding between
individuals
and account numbers) ... however there was 1) no requirement
to divulge
such bindings during retail transactions and 2) x9.59
applies equally
well to stored-value retail transactions (where there is
much less
frequently a requirement imposed for "know your
customer".

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Fri, 30 Mar 2007, Ian G wrote:
> The reserve assets' location(s) is fairly important
from a customer trust
> perspective.  People look at the overall safety and
make their own judgements.
> One person might decide that New York is safe and
another will find that a
> horrible thought (for those who follow this arcane
field, there was a big bust
> of a dodgy operator in NY some months back).  Having
said that, once a system
> is up and running, and is robust, it seems that moving
the assets from one
> continent to another has not been a source of concern
to many users.
> 
> The issuer himself is pretty important.  His physical
location isn't so
> important -- everyone flies around these days -- but
nobody has ever been able
> to gain trust in a system to date without reference to
a real meatspace hook.
> And for good reason ... how do you take him to court? 
(And if you are
> thinking of extra-jurisdictional transactions, how do
you beat him to a pulp
> with a baseball bat?)

There's another point:  Suppose you come up with an ideal
system which
preserves secrecy in the way you'd like.  How are you going
to convince
assorted government agencies (eg the US Treasury Dept and
its kin in
other countries) that your System won't be used for money
laundering,
terrorist financing, or other nefarious purposes?

[N.b. I am *not* trying to start a flame war here, and in
particular I
am *not* accusing anyone on this mailing list of nefarious
purposes.
Rather, I'm asking a serious question about the practicality
of anonymous
(crypto-enabled) financial services in the 21st century,
namely, will
governments be willing to allow them to operate?]

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply"
<jthornaei.mpg-zebra.de>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the
powerful and the
    powerless means to side with the powerful, not to be
neutral."
                                      -- quote by Freire /
poster by Oxfam

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Hello,

On 29/03/07 21:30, Steve Schear wrote:
> Here is the situation.  An on-line financial service,
for example a DBC
> (Digital Bearer Certificate), operator wishes his meat
space identity,
> physical whereabouts, the transaction servers and at
least some of the
> location(s) of the service's asset backing to remain
secret.  The
> service provides frequent, maybe even real-time, data
on its asset
> backing versus currency in circulation. The operator
wishes to provide
> some assurance to his clients that the backing and the
amount of
> currency in circulation are in close agreement.  The
mint's backing need
> not be in a single location nor in the sole possession
of the operator.
> 
> I realize this is a governance question but I suspect
that crypto/data
> security may play a key role.
> 
> Some questions:
> If independent auditors are used do they need to know
the operator's
> identity?


Putting the crypto capabilities aside for a moment, what is
the purpose
of auditing an anonymous legal entity?

Auditing, as I see it, can be used to serve two systems:

	1. An intrinsically-enforced reputation system
	2. An extrinsically-enforced legal system

When I take my hard earned money and deposit it with the
local branch of
ABC bank, I do it while relying on two things:

	1. The bank is part of a national legal trademarking system
that
assures me that this branch having this nice red
"ABC" logo, is the same
ABC Bank that all my friends use, along with millions of
others, and so
far, they haven't been fooled and their money hasn't yet
been stolen.

	This #1 is something I can get from a pseudonym based
system that is
accompanied by some auditing I trust, even if the bank is
completely
anonymous. In the optimal installation you try to achieve
the auditor I
trust will be able to tell me: "This bank, that you do
not know where it
is, and so don't I, has the backing for the currency it has
in
circulation." I will also be able to tell it's the same
bank my friends use.

	2. The bank is part of a legal *enforcement* system, such
that if the
bank takes my hard earned money and refuses to give it back
to me, the
*human* manager of the bank will be put in *physical*
handcuffs and
taken to a physical prison, where he cannot physically
exercise his
freedoms, such as go to a pub, see his kids, etc. No
web-site extortion,
no reduction of virtual credibility points, not even bad
publicity;
jail. Real jail, with non-chosen roommates and bad meals. I
want to know
that the enforcement system that the bank is subject to is
one that can
lead to real jail before I trust a web-site with my real
money. This is
along the lines of the baseball bat that Ian mentioned.

	This is something I cannot get from a system in which there
may be
auditing, but there is no chain connecting the digital world
(as
intrinsically-enforced as it would be), and the physical
world, that
offers better enforcement means, better matching my money's
worth.

The enforcement that is offered by the legal system is tied
to the
physical world and thus requires identifiability and
personal (flesh --
not username) accountability. You can have a system do
without it; have
only intrinsic enforcement without tying to the physical
world, but I
believe its enforcement will never be strong enough to win
the trust of
the masses when it comes to hard earned money.

At the end of the day, say everything works perfectly by
your model, and
the intrinsic system can prove that there is a coin of gold
for every $x
in circulation. How does the user know that he will ever see
the sums he
put in circulation. He has a receipt, of course, but a
receipt is just a
bunch of bits. These bits may prove to a third party that
justice is
with the user, but what will link this justice back to money
if the
bank's owner doesn't feel like paying?

I know this is not completely related to the questions you
presented,
but more to the rationale of the entire system. I am just
trying to
understand this better.

Regards,
Hagai.

-- 
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Ian G wrote:
> OK, on the face of it, you seem to have been doing
triple entry (with 
> the twist of a hash).  Actually I am not so sure that
it is even twisted 
> ... as you are simply saying that someone somewhere was
logging the 
> hash;  but not who was storing the receipts.
> 
> To point:  is this written up anywhere?  <gollum>
 did I really ask 
> that? ;)
> 
> I wrote this concept up in a paper and am very happy to
expand to 
> include other art and implementations, given more than
copious free time...
> 
> http://iang.
org/papers/triple_entry.html
> 
> I'm integrating (or should be) the work that Todd Boyle
has done on 
> accounting, because his concept is more rather than
less analogous.

re:
http://www
.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous
financial services

so applying x9.59
http://www
.garlic.com/~lynn/x959.html#x959

mapping to iso 8583 (i.e. credit transactions, debit
transactions ... and even some
number of stored-value transactions carried by some
point-of-sale terminal and
... at least part of the financial network)
http://www.g
arlic.com/~lynn.8583flow.htm

you have the standard iso8583 financial transactions with a
x9.59 addenda ... that includes
a digital signature, a hash of the receipt and some misc.
other stuff.

existing infrastructure advises that both merchant and
consumer retain (paper) receipts (in
case of disputes). x9.59 financial standard didn't
specify/mandate how that might be
done ... but provided for support for applications for
doing.

the financial transaction was already required to be
archived/logged for all sorts of
regulations and business processes (as evidence some number
of recent breach references). 

In the mid-90s, the x9a10 financial standard working group
had been given the requirement
to preserve the integrity of the financial infrastructure
for ALL retail payments. In numerous
other references I've mentioned that doing required taking
into account all sorts of
considerations as part of x9.59 standard (including
countermeasures to fraudulent transactions
from breaches), it had to be extremely lightweight because
of numerous considerations when
you are asked to consider ALL retail transactions (including
looking forward to various c
ontactless, wireless, cellphones, transit turnstyles, etc),
and maximizing the optimal
use of all the existing processes and flows.

In any case, as a result, the "x9.59" transaction
would be logged/archived as part of existing standard
financial transaction processes ... which includes the
digital signature against the
full transaction ... where the full transaction ... along
with the digital signature
is being logged ... including the receipt hash and the
additional x9.59 specified fields.

the "receipt", that is hashed, isn't specified as
part of the x9.59 protocol standard
... but is assumed to be whatever is necessary to support
resolution, in case of any 
dispute (at least the equivalent of saying that both the
merchant and consumer retained
paper receipt copies in the case of dispute).

we actually may have done too good a job. a lot of efforts
that have worked on doing similar
or related efforts ... essentially viewed it as profit
opportunities. the x9a10 standards
worked view all the "stuff" as added expense ...
to be aggressively eliminated as much as
possible. For instance in the AADS chip strawman
http://www
.garlic.com/~lynn/x959.html#aads

in the mid-90s, i would semi-facetiously say that we would
take a $500 mil-spec part, 
aggressively cost reduce it by 2-3 orders of magnitude,
increase its security/integrity,
have it form-factor agnostic (as well as being able to meet
contactless transit turnstyle 
requirements).

to compound the problem ... we also did a bit of work on
being able to change the
institutional-centric "something you have"
authentication paradigm to a person-centric
paradigm ... i.e. rather than having one
"something" per institution ... you could have
one (or a very few) "somethings" per person (could
be viewed as creating the "something you are"
biometric authentication analogy for "something you
have" authentication). misc. past
posts mentioning 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

so having something that was aggressively cost reduced by
2-3 orders of magnitude, more
secure ... and instead of having one per
institution/environment (that a person was 
involved with), they would have only one (or a very few).
overall this could have represented
possibly four orders of magnitude cost reduction (that many
others were viewing as potential
profit opportunity).

in any case, who would be the stack-holders interested in
something that eliminates nearly all
fraud and nearly all costs?

a few past posts mentioning working on change-over to a
"person-centric" paradigm:
http://www.
garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP:
snake oil or good idea?
http://www
.garlic.com/~lynn/aadsm25.htm#42 Why security training
is really important (and it ain't anything to do with
security!)
http://www
.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in
messaging
http://www.
garlic.com/~lynn/2006d.html#41 Caller ID
"spoofing"
http://www.
garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol
Approved as ISO 18000-6C
http://www.
garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.g
arlic.com/~lynn/2006q.html#3 Device Authentication - The
answer to attacks lauched using stolen passwords?
http://www.
garlic.com/~lynn/2007b.html#12 Special characters in
passwords was Re: RACF - Password rules
http://www.
garlic.com/~lynn/2007b.html#13 special characters in
passwords
http://www.
garlic.com/~lynn/2007d.html#12 One Time Identification,
a request for comments/testing

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

re:
http://www
.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous
financial services
http://www
.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous
financial services

My wife has been gone five years and I've been gone for over
a year (they had
corporate re-org in Dec '05) ... and we have no
rights/interest ... but they
continue to trickle out
http://ww
w.garlic.com/~lynn/aadssummary.htm

latest today (3Apr2007) ... hot off the press:
http://patft.uspto.gov/
netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fneta
html%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50
&d=PTXT&S1=7200749.PN.&OS=PN/7200749&RS=PN/7
200749

Method and system for using electronic communications for an
electronic contract

Abstract

A method and system for digitally signing an electronic
contract document. An electronic
communication contains an identifier, a message, which
includes the document, and a digital 
signature generated with a private key of an asymmetric key
pair (247). The identifier may be 
used to retrieve a corresponding public key (287) and
account information pertaining to the 
sender of the message. The public key may be used to
authenticate the sender and the message. 
A device containing the private key may be used to protect
the privacy thereof. The device may 
also generate a verification status indicator corresponding
to verification data input into the device. The indicator
may also be used as evidence that the sender of a contract
document performed 
an overt act in causing the electronic communication to be
digitally signed. A security profile 
linked to the public key in a secure database indicates
security characteristics of the device. 

... snip ...

for a little drift ... slightly related to this recent
posting in sci.crypt
http://www.
garlic.com/~lynn/2007g.html#40 Electronic signature
outside Europe

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com