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
>