edited spec, added hmac generation function + test

docs/onionr-draft.md

@@ -14,7 +14,7 @@ There are no central servers and all traffic is peer to peer by default (routed
 User IDs are simply Tor onion service/I2P host id + PGP fingerprint.
 Clients consolidate feeds from peers into 1 “timeline” using RSS format.
 Private messages are only accessible by the intended peer based on the PGP id.
-Onionr is not intended to be a replacement for Ricochet or OnionShare.
+Onionr is not intended to be a replacement for Ricochet, OnionShare, or Briar.
 All traffic is over onion/I2P because if only some was, then that would make that traffic inherently suspicious.
 ## Goals:
     • Selective sharing of information with friends & public
@@ -54,6 +54,9 @@ Clients MUST use HTTP(s) to communicate with one another to maintain compatibili
     Posts can contain text and images. All posts MUST be time stamped.
     Images SHOULD not be displayed by non-friends by default, to prevent unwanted viewing of offensive material & to reduce attack surface.
     All received posts must be verified to be stored and/or displayed to the user.
+
+    All data being transfered MUST be encrypted to the end node receiving the data, then the data MUST be encrypted the node(s) transporting/storing the data,
+
      Posts have two settings:
         • Friends only:
             ◦ Posts MUST be encrypted to all trusted peers via AES256-HMAC-SHA256 and PGP signed (signed before encryption) and time stamped to prevent replaying. A temporary RSA key for use in every post (or message) is exchanged every X many configured post (or message), for use in addition with PGP and the HMAC.
@@ -65,7 +68,7 @@ Clients MUST use HTTP(s) to communicate with one another to maintain compatibili
     When both peers are online messages SHOULD be dispatched directly between peers.
     All messages must be verified prior to being displayed.
 
-    CLients SHOULD allow configurable message padding.
+    Clients SHOULD allow configurable message padding.
 ## Spam mitigation
 
 To send or receive data, a node can optionally request that the other node generate a hash that when in hexadecimal representation contains a random string at a random location in the string. Clients will configure what difficulty to request, and what difficulty is acceptable for themselves to perform. Difficulty should correlate with recent network & disk usage and data size. Friends can be configured to have less strict (to non existent) limits, separately from strangers. (proof of work).

onionr/core.py

@@ -49,7 +49,7 @@ class Core:
         conn = sqlite3.connect(self.peerDB)
         c = conn.cursor()
         t = (peerID, name, 'unknown')
-        c.execute('Insert into users (id, name, dateSeen) values(?, ?, ?);', t)
+        c.execute('Insert into peers (id, name, dateSeen) values(?, ?, ?);', t)
         conn.commit()
         conn.close()
         return True
@@ -62,7 +62,7 @@ class Core:
         conn = sqlite3.connect(self.peerDB)
         c = conn.cursor()
         c.execute('''
-        create table users(
+        create table peers(
         ID text not null,
         name text,
         pgpKey text,
@@ -154,4 +154,5 @@ class Core:
         '''
         generate and return an HMAC key
         '''
-        return
+        key = base64.b64encode(os.urandom(32))
+        return key

onionr/tests.py

@@ -90,6 +90,17 @@ class OnionrTests(unittest.TestCase):
             myCore.generateMainPGP()
             if os.path.exists('data/pgp/'):
                 self.assertTrue(True)
+    def testHMACGen(self):
+        print('--------------------------')
+        print('running daemon queue test')
+        # Test if hmac key generation is working
+        import core
+        myCore = core.Core()
+        key = myCore.generateHMAC()
+        if len(key) > 10:
+            self.assertTrue(True)
+        else:
+            self.assertTrue(False)
     def testQueue(self):
         print('--------------------------')
         print('running daemon queue test')