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

How does one trust the key (that its not merely authenticating +compromised+ "material" (to use an American phrase)? The key becomes the target of deception...

At scale, it's hard. On small scale, its as easy as its always been (just send guy with suitable briefcase with stuff inside ...on a plane to Manilla...)

-----Original Message-----
From: Melvin Carvalho [mailto:[email protected]] 
Sent: Tuesday, November 30, 2010 1:48 PM
To: Peter Williams
Cc: foaf-dev-RyYwo1q5J+qsOXdr9/[email protected]
Subject: Re: [foaf-dev] playing with reputations and non secret encryption, suited to the "socialization semantics" of foaf groups in an FOAF+SSL context.

Did you think about each foaf Group having a shared secret?  Say an AES 256 key?

On 30 November 2010 22:42, Peter Williams <[email protected]> wrote:
> 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:foaf-dev-bounces-RyYwo1q5J+qsOXdr9/[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
>