Re: [foaf-dev] playing with reputations and non secret encryption, suited to the "socialization semantics" of foaf groups in an FOAF+SSL context.

I feel a bit better, since the core "turn around" I used is present in the author's own  http://www.cesg.gov.uk/publications/media/rsa.pdf.

The method in rsa.pdf might be built upon now to be useful to FOAF (once subverted from its original UK intent of spying on folks, using systemic covert methods).

Since 2 entities can each now determine that a common authority asserts that each of their introducers are trustworthy and are members of the same foaf:group (denoted by URI), the 2 entities now can engage in rdf.pdf (acting as Alice and Bob, formerly UK split-duty key escrow/generating authorities). That is, they form their own 2-element SUB foaf:group of URI and go make "some key".

Having done so, they might engage in foaf "multicast" - acting as a key distribution source for today's group key. That is, having jointly spent a day calculating an N*N modulus (under the splitting rules) on a commodity 2G PC (a day of a 2G PC is nothing, note... remembering it took a day to calc 512 bit personal RSA keys on a 1/2G university-grade DEC workstation... when i FIRST started...), they might now share the "group key" with anyone who can induce the group-owner to confirm that they are probably valid member of the group (see earlier msg). By return, validated members are sent each half of the (cleartext) RSA parms that acts as an decrypt-KEK (key encryption key), that can unwrap today's transport encryption keys (TEKs) for the "group messages"

This would be useful to parties with triple stores, who want to replicate the model to whomsoever are members of replication-Group G. My triples may be important, but no one in their right mind will be trusting me (but they do trust Henry, say, on account of personal knowledge). By peering with Henry, I can combine confidences so as to create sufficiently trustworthy key applicable to groups of large size - that I used then to replicate/broadcast my XYZ triple store.


From: foaf-dev-bounces-RyYwo1q5J+qsOXdr9/[email protected] [mailto:[email protected]] On Behalf Of Peter Williams
Sent: Tuesday, November 30, 2010 12:21 AM
To: foaf-dev-RyYwo1q5J+qsOXdr9/[email protected]
Subject: [foaf-dev] playing with reputations and non secret encryption, suited to the "socialization semantics" of foaf groups in an FOAF+SSL context.


Assume a foaf-group exists, has name URI, and its webserver offers the group's foaf card over FOAF+SSL. The foaf card contains statements for the integers: a, r, and M. a is a public function of the URI (given modulus M), and r is a (self-signed) signature of a. From the math (see ref below) anyone can test that URI => a => r. M is claimed to be unique to the group, being the multiple of two large primes (P & Q) chosen at random by the owner of URI.

Next, anyone with a webid (e.g. w) can claim to be a member of the group by applying the group's modulus M. To do so, w includes (r , Aw and Rw) in her/her foaf card - where Rw is a signature of r. Taking the form of the the base case, anyone can test that r => Aw => Rw, and induce URI => Rw.

Anyone with a webid w2 can claim to be a member of the group AND recognise w as another member of the group. To do so, w2 reads Rw from w's foaf card using FOAF+SSL, and includes in his/her foaf card (Rw, Aw2, Rw2). This is the inductive hyptothesis.

In essence, we have made a reverse hash chain from M to Rw2, where M is assumed to be a public identity function of a (foaf-group) URI. Only the real owner of the URI has P and Q factors of M, unlike all usurpers of M. The FOAF+SSL design assumption holds, such that only the owner of a webid can control the contents of the referenced FOAF card

Anyone may now ask the owner of the group URI (identified by M) to mint a random number t (mod M) and to state then that Rw2 is trustworthy (as of now) for the singular purpose of recognizing  Rw1 as a group member  (or that Rw2 is not trusted as a recognizer of Rw1). The URI's Owner may state Rw2<Rw1>  => true/false, by publishing a counter-signature statement  s for either true or false, where s = f(t, M, Aw2) = (t + Aw2/t) mod M

Party verifies the counter-signed statement using Rw2 (and M). Verification establishes URI is the true owner of M, is a foaf-group that someone claims to belong to, and URI trusts w2 to state that w1 is a group member of said group.

Based on my rather limited understanding of the one way functions in http://cryptome.org/nsa-nse/nsa-nse-04.pdf,  twisted around somewhat to do signing and hash chaining.

CAVEAT: I don't pretend to understand the complexity analysis of the underlying math..., or the algebra being leveraged. More than possible that in changing application function, I've introduced fundamental flaws due to inappropriate ciphering...

_______________________________________________
foaf-dev mailing list
foaf-dev-RyYwo1q5J+qsOXdr9/[email protected]
http://lists.foaf-project.org/mailman/listinfo/foaf-dev