Day 64/365 or day 21/28 for Singing Phoenix

What I accomplished today

  • Finalized long term plan for Sapphire Pack pivot [20]
  • Took down deep work from Thinkific and SapphirePack [13]
  • Planning the four targets for fedration including how each will work [87]

Singing Phoenix

I just song 4 seperate songs and didn't do theory. I'll get back to theory tomorrow.

Multiple Keyslots and key exchange and sharing notes and bilateral communication

Here's how the current encryption is used:

Your passphase -> derived password

Derived password -> password for specific note

So what we need to do is provide multiple "keyslot" that is multiple:

Derived password1 -> password for specific note
Derived password2 -> password for specific note
Derived password..-> password for specific note

Here's the beauty of this modification:
1) Current and older SN systems will still run and should completely ignore "extraneous" fields (just like CSS does)

2) We can implement filling in these extra keyslots by using some sort of key exchange protocol that won't expose the derived password.

So the biggest problem is that:

1) We need to know which key to use to decrypt the "derived password" to get to actual password to modify the note.
2) We don't want to reveal the derived password since this is the key to all of the persons own private notes

A way to solve this:
1) Using a keymanagement extension of some sort.
This extension is part of the sharing notes system and what happens is:
1) Someone creates the note and shares it to one or more other people
The shared note extension figures out where the other people are and submits a DIME like email to our homeserver.

This is a really big design decision. Should the home server be trusted? Mostly. Should other home servers be trusted? Not to much. Why is this important, we want the person using a home server to not reveal who they are talking to (this is a fundamental right). Having a point to point communication makes it easier to figure out who is talking to who. Making it optional means that most people will likely opt for the quickest option, meaning the DIME protection is redenered moot. Therefore forcing all inter server communication to occur via DIME protects everyones communication patterns. However endpoint analysis can still occur which can be addressed using several counter techniques. I'll list just one such as:

1) Sticky endpoints communication.
When a home server recieves a message, it'll send it to multiple devices (most of which will just discard the data). This makes endpoint correlation attacks slightly harder to do. However once a home server has people using the server globally, endpoint attacks become almost impossible since many people will be using the home server at all times around the clock.

2) Our homeserver doesn't know who we're inviting or communicating with. Just that we want the homeserver to send a message to another homeserver.

At this point we could have the protocol receive a delivery report from the other home server. This delivery report would just be the envelope hash which we can then be assured our home server actually delivered the message.

3) The other people recieve the unencrypted notes content and drop it into a note they create on their side. The beauty of this system is that each person has their own UUID that refers to the same note, making it hard to track which note is shared with who.
The person would generate a random encryption key and store that encryption key in some sort of "key ring". This means that in the event that encryption key is figured out, the only thing the adversary would have gained is access to only that note.

Basically we generate a random encryption key and that encryption key is used to code one of the keyslots. After the keyslot has been coded keyslot is send back.

Now all further updates are done encrypted (if not online at same time, just like regular syncing) or using websockets (if online at the same time).

The note is treated like a regular note, except we can establish websocket connections and synchronize the note in realish time. The exact protocol is something that still needs to be fleshed out. However in the event that the synchronization extension isn't used it should be just a regular note and editable as such.

Why not use something like PGP or something? That would involve adding unnessecary cryptographic code and giving SN a bigger attack surface

The websocket connection will occur as such:

Person ----- Home server 1 ----- Ohter home server ---- Other person

This means that as more people are sharing notes at the same time it's harder to see which people are editing the same note. The protocol will likely use a fixed block and fixed transmission interval to make this even harder to correlate.

Here's how a fixed block and fixed transmission interval works:

1) We transmit 1 KB of data encrypted every 100 MS.
2) In the event that we have nothing to transmit we transmit an empty 1KB of data.

This leads to the max data transmission of 900 characters per 100 ms or around 9000 characters per second.

This means that if you decided to paste in all of War and Peace, everyone you're live editing with would get the entire book in just 67 seconds. However there a few sneaky ways to make this data transmission even faster such as arbitrary transfer of binary data between home servers. (Which again will likely be fixed at 1MB size transfer blocks.) Since transfering data between home servers could become REALLY expensive that is one person transfering 4GiB file would take 6.8 hours.

What we do is have a series of binary blobs which range in size from 10 MB to 1TB in fixed sizes that are stored on BinaryAssets servers. These servers are extremely simple in that they recieve data, generate an access key and the first home server sends that access key to the other server via DIME. The second home server would download that data and store it until the person can handle the data. Similar to mail and a post office.

# Peer to peer human based trust

1) We aren't robots. Our federation shouldn't treat us like ones.

We'll assume that each federation maintains a 14 day backup of notes and if they are running a Binary Assets Servers that data is backup for 14 days as well.

In the event that a server is compromised we have 14 day recovery window.

2) Asking to verify keys and other long hexadecimal string are stupid.

What we'll do is use telegram's idea of showing a series of emojis and words.

So if I want to join the federation, I would speak to one of the members and obtain a federation joining key (FJK) this is done by telling them the 5 words my server is showing me. They enter that into their server and get back the words I enter on my system as a confirmation.

This basically does a secure bridge, transfers the federation keys used for authenticating other federated servers and taps into the web of trust.

Each federated server can ask for updates on servers within the federation by querying any server with that servers last status.

A status includes dump of keys and other key infrastructure support systems such as changes, revokations and such.

By removing the key from DNS management we open ourselves up to one type of attack but the keys prevent such an attack from succeeding since our servers will realize we're speaking to the wrong server and stop communicating.


You'll only receive email when Cubes publishes a new post

More from Cubes