Private Peer File

The Private Peer File is never given out to any other peer. However, the peer file can be stored with a trusted service as the contents are encrypted. The contents of the file must be encrypted to prevent unauthorized access to the private key that is the matching pair for the public key in the Public Peer File. This file can be used to prove ownership of the Public Peer File.

The file does not carry any recommended extension and is managed by the client application that must maintain the security and integrity of the file.

The contents of the file are as follows:

Section “A”

  • Cipher suite to use for all hash computations and encryption operations related to contents of the private peer file and this cipher suite must match the public peer file’s cipher suite (note: this does not apply to signed XML segments which have their own method to describe algorithms and key selection)
  • Peer Contact’s full URI (to know how to locate the peer universally).
  • Salt (base-64 encoded binary salt)
  • ‘Private Peer File secret’ proof, hash = hash(“proof:” + <peer-contact-id> + “:” + <private-peer-file-secret>))
  • Encrypted private key, key = hash(“privatekey:” + <salt> + “:” + <private-peer-file-secret>), iv=hash(“privatekey:” + <salt>)
  • Encrypted Public Peer File, key = hash(“peer:” + <salt> + “:” + <private-peer-file-secret>), iv=hash(“peer:” + <salt>)
  • Encrypted contact profile secret, key = hash(“profile:” + <salt> + “:” + <private-peer-file-secret>), iv=hash(“profile:” + <salt>)
  • Encrypted private data, key = hash(“data:” + <salt> + “:” + <private-peer-file-secret>), iv= hash(“data:” + <salt>)

Section “B” (encrypted using the method described in Section A)

The format of the Private Peer File is defined so it can be stored on server (should a client desire to do so) with only clients that have the correct “private peer file secret” being able to request download of the file without the server knowing the value of the data contained within the file.

The Peer Contact’s URI is used to indicate which Public Peer File the Private Peer File is correlated.

The key salts combined with hash input phrases are used to ensure that the “private peer file secret” is not directly used to encrypt more than one piece of data.

The “private peer file secret” proof is used so a server can verify a client does have the correct information to request download of the Private Peer File. Only a client that knows the “private peer file

secret” would be able to generate the correct key proof in a challenge. The contact ID is combined with the secret to add extra complexity into the secret to ensure no two users have the same stored secret resulting hash should the private peer file is published into a database and two users use the same secret value.

The encrypted private key is the private key pair matching the public key in the Public Peer File.

The encrypted Public Peer File is a complete encryption of the Public Peer File (i.e. all sections), thus requiring only one file to store both the public and private key.

The encrypted contact profile is the secret key used to decrypt a contact profile (which is stored in an encrypted fashion elsewhere).

The encrypted private data is extension data for use for whatever purposes required by a client.

Security Considerations

The contact URI must be the computed hash based on Section “A” of the Public Peer File. The salt must be cryptographically random. Both sections of the private peer file must be signed to ensure the contents of the private peer file have not been modified by another entity and must be verified by the client before the private peer file is used.

All data in this file is considered secure thus all data must be encrypted.

Example Private Peer File

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<privatePeer version="10">
<sectionBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
 <section id="A">
  <cipher>sha256/aes256</cipher>
  <contact>peer://example.com/ab43bd44390dabc329192a392bef1</contact>
  <salt>YzY4NWUxMGU4M2ZjNzVkZWQzZTljYWMyNzUzZDAwNGM4NzE5Yjg1</salt>
  <secretProof>NDlkZWI0MzFhYmUxOWQzNWJkNDkzMWZhMzFmMw==</secretProof>
 </section>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
   <Reference URI="#A">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
   </Reference>
  </SignedInfo>
  <SignatureValue>G4Fwe0E/YT=</SignatureValue>
 </Signature>
</sectionBundle>
<sectionBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
 <section id="B">
  <encryptedPrivateKey>jk483n2n~3232n/34nk323j...32fsjdneen2311=</encryptedPrivateKey>
  <encryptedPeer>43j2332944bfdss323bjfjweke2dewbub3i...22dnnewne321~nn32n3j2/44=</encryptedPeer>
  <encryptedContactProfileSecret>ZWUxZGQz...NjgzMTU3Y2JhZjhhNA==</encryptedContactProfileSecret>
  <encryptedCaptcha>WkdNME16UXhPRE...JqTVV3WWpNek5tSTROems1T1dVPQ==</encryptedCaptcha>
  <encryptedPrivateData>ZGM0MzQxODBjMTgxMDY2NGQ4MWE...GUwYjMzNmI4Nzk5OWU=</encryptedPrivateData>
 </section>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
   <Reference URI="#B">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
   </Reference>
  </SignedInfo>
  <SignatureValue>MC0E~LE=</SignatureValue>
 </Signature>
</sectionBundle>
</privatePeer>