Thanks for the living hell, and question about OpenSSL
Patrick Chkoreff
patrick at fexl.com
Fri Apr 25 18:54:33 PDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim May wrote:
>> I'm writing "(unblind (sign (blind X))) = (sign X)" on the board one
>> hundred times.
>
> You don't need to take our word for it--you need to see why modern
> cryptography avoids trust issues almost completely.
No no, I'm not writing it out of blind obeisance. I actually see how
and why blinding achieves anonymity and avoids the trust issue. When
someone presents a note for redemption, the server literally has no way
of knowing to whom that note was originally issued. All it knows, and
all it can *possibly* know, is that it is a valid note that has not
been redeemed.
In the previous scheme I was simply not aware of this design goal. I
did not even view my system as implying a promise not to look. I
simply viewed it as a system that does not in fact look. But I see now
why that's a problem, because (1) a system that does not look now can
start looking tomorrow and (2) users have no way of knowing either way.
So the promise of which you speak is in fact implied, as I know today
after my cypher-hangover this morning. Nothing a four mile walk with
the dog couldn't cure.
> I suggest that you dig up Chaum's "Communications of the ACM" paper
> from 1985: "Transaction Systems to Make Big Brother Obsolete." I read
> it when it came out, and it triggered many ideas. It's online, or was
> as of a few years ago.
That's funny, it was a 1989 CACM article by J. Steensgaard-Madsen that
triggered my ideas about purely function languages like Fexl. Classic
stuff from the 80's. Thanks for the intriguing reference.
> Also, look at his paper on "Dining Cryptographers" to see how
> information-theoretically secure messages can be sent.
>
> Forget worrying about the details of various ciphers in Schneier's
> book, at least until you have grasped the essence of not relying on
> trust or "I promise not to look" b.s. schemes.
Right, actually I'm scribbling out a system overview in terms of
functions with specific properties independent of their implementation
in modular arithmetic or anything else. Basic relationships like
(encrypt (decrypt X)) = X, (unblind (sign (blind X))) = (sign X),
(sign X) = (decrypt (hash X)). Definitions like a 'note' is <X, (sign
X)>. Identifying which functions are secret to whom and which are
public. Generation procedures such as: given a public 'encrypt'
function, generate a random pair of functions <blind, unblind> with
specific desirable properties. All without reference to any specific
number-theoretic + padding implementations.
This helps me get a feel for the whole flow of the system and all it
implies. That plus a strong platform like OpenSSL (I presume) should
yield good application code. I'm not much of a GUI guy, so I may just
do a reasonably substantial API layer, a tight set of user-side command
line primitives, and a socket-based server program. Or I may just
throw in the towel and burrow around in the Lucrative code, but I'm not
much of a Java guy either.
> BTW, a more abstract book is Oded Goldreich's "Foundations of
> Cryptography--Basic Tools," 2001. A little disorganized in places, but
> lots of core concepts.
>
> When you have fully grokked the way messages can be sent without any
> practical way of tracing their origin, as in the dining cryptographers
> example, your eyes will be opened. And zero-knowledge interactive proof
> systems (ZKIPS) will blow your mind. Never again will you argue in
> terms of "trust me" and "so long as they don't subpoena me" and "I
> promise not to look."
Again, I must stress that I was never *knowingly* advocating that users
must "trust me." I was not aware until yesterday that "trust me" was,
in fact, an implied premise in my system. Certainly if there was some
meta-certain way for users to know that my system was not keeping
records, it could work just fine. But there isn't, so it couldn't.
> (My simple explanation of ZKIPS in terms of demonstrating a Hamiltonian
> cycle for a graph is in the archives, from around 1992-3.)
Sounds great. Thanks again.
- -- Patrick
http://fexl.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBPqnm4FA7g7bodUwLEQKYrwCg96E4VRcEhFU2jfKspzN1qvY5pM4AoJgl
QLFXpOib+vwB1WSDTiJQI/8X
=vZt3
-----END PGP SIGNATURE-----
More information about the cypherpunks-legacy
mailing list