Encryption Research

[tymc7]

Any information you find, let's comment on this issue. Slack has a tendency to delete conversations after a certain amount of time.

[tymc7]

Started doing some research and plan to pick it up more tonight. Here is my list of links that i've found helpful so har:

• End-To-End Encryption
• Broadcast Encryption - This may be the best option for encryption
  • Implementation
  • Diffie–Hellman key exchange
• Galois/Counter Mode - Possible Idea
• W3 Web Crypto API - For the front end
• Why Can’t Online Social Networks Encrypt?
  • Article that has 3 different encryption setups. Not sure if we can use them but definitely helps with thinking about it.
• One-To-Many Encryption Technique

Encryption Strategies:

• WhatsApp Encryption Whitepaper
• 1Password
• Telegram Encryption
• Signal Encryption

Encryption Techniques:

• Curve25519
• AES
• HMAC

Other Useful Links:

• http://lollyrock.com/articles/nodejs-encryption/
• https://www.npmjs.com/package/node-aes-gcm

[yungRoz]

I've gone ahead and summarized some of my research thus far, which currently is just a bunch of youtube videos.

Computerphile videos on DH

Overview w/ colors [source]

Each user has a private key. Let these be represented as p_a for Alice, p_b for Bob, and p_s for the server. Alices mixes her private key, p_a, with server key, p_s, resulting in a hard to reverse combination, (p_a)(p_s), that is passed over the server to Bob. Bob does the same and passes his private/server combination, (p_b)(p_s), to Alice. Both Alice and Bob add their private key to the combination they received from the other, resulting in a shared key the server doesn't have access to, (p_a)(p_b)(p_s), - note the central operation of DH is commutative and thus both Alice and Bob end up with the same key.

Problems w/ DH [source]

What is the weakness of DH? A man in the middle attack. Suppose there is Shawn. Shawn might pretend to be Bob, and send his (p_sh)(p_s) to Alice. Since Alice doesn't know what Bob's incoming combined key looks like, she might presume Shawn is Bob and begin sharing secrets with Shawn. This issue can also work in the other direction where Shawn tricks Bob into thinking that he's Alice. Shawn can then faciliate a conversation of secrets between Alice and Bob all while listening in. How is this resolved? Signature verification. For example w/ RSA. When Alice initiates secret sharing by sending her combined key, (p_a)(p_s) to Bob. Bob sends his combined key along with a hashed version of the key signed with his private key. Alice performs signature verification: she takes the data and performs the same hashing function Bob used. She then compares this to Bob's hashed message decrypted by his public key. If they match, the message was sent by Bob .

W3 Web Crypto API Workshop [source]

Jusitifications

Web Crypto uses native crypto libraries from the browser. Implemented encryption algorithms in JavaScript can be slow and insecure. Support across browser and os except ios (based on 2016 video). TLS does not provide end-to-end security.

API: window.crypto

API lives in Browser's DOM, is not part of JS, lives in window.crypto object. This window.crypto object has a method window.crypto.getRandomValues(buffer), which stores cryptographically strong random numbers in a chunk of memory and returns this chunk to you.

Code Example:

// Declare a new buffer, 16 byte array

buf = new Uint8Array(16); // Uint8Array returns unsigned 8 bit arrays with 0s
window.crypto.getRandomValues(buf); // fills with random values 

API: window.crypto.subtle

Another part of the API lives in window.crypto.subtle that contains asynchronous methods, that return promises instead of using callbacks

Code Example:

// line by line explanation: 
// create a key usable for the AES-CBC algorithm, of length 256
// boolean says whether key can be exported or not
// usage: to be used for encryption and decryption 
p = window.crypto.subtle.generateKey(
    {name: "AES-CBC", length: 256}, 
    true, 
    ["encrypt", "decrypt"]
);     

// regardless of whether or not promise is resolved
// resolved promise handling can be defined with then method
p.then(function(result) {
    key = result; 
    // result is an opaque CryptoKey object
   // can be exported if allowed by key creator
}); 

//error handling
p.catch(function(err){
  //handle error
}); 

Conclusion:

The link provides code lab examples for asymetric encryption, passphrase encryption, and signature verification. The first 2 labs may not be very useful. The last may be useful in DH.

[tymc7]

I watched a few different videos on YouTube, came up with this solution?

Idea 1

• Alice has a public key which is known by the server and a private key which is only known to her
• Bob has a profile encrypted by his private key. This is so that it can be decrypted using his public key
• The server has a public and private key used for sending and receiving data securely. This is routinely updated (every 30 min? 1 hour?)

1. Alice requests Bob’s profile from the server
2. The server first get’s Bob’s profile from the database (which is partially encrypted)
3. The server then check’s if Alice and Bob are friends
4. If they are friends, the server will then include Bob’s public key, along with his profile, in the payload. If they are not friends, only the base information (which isn’t encrypted on the server) is added to the payload. The server then encrypts the payload using Alice’s public key and sends over the network.
5. Alice receives the payload, decrypts the payload using her private key. Then the front-end takes the information provided from the payload and displays.

Issues:

• Not End to End encrypted
• Decryption happens on the front end, so payloads will still be encrypted
• Encrypted enough? 😬

[thegeophysicist]

Similar Ideas:

• Minds – Not well documented
• Hacker News - A decentralized social network with end-to-end encryption
• Diffie-Hellman with more than two parties

Web encryption:

• What’s wrong with in-browser cryptography?
• Web-browser encryption of personal health information

---

I looked a lot into group messaging solutions. I think there's similarities with what we're trying to do.

Group Messaging:

• Signal – Private Group Messaging
• Secure Messaging – Page242
• Improved Group Off-the-Record Messaging

[thegeophysicist]

I had an idea similar to how group messaging does things:

Idea 2 - DH-like key arrangement to generate shared secret to view friends' profiles

1. Alice and Bob have their own separate public/private key pairs which they use for authenticating with the server.
2. The server uses something like the Diffie-Hellman operation for more than two parties to generate the key arrangement for Alice and Alice's friends (e.g., Bob). This generates a shared secret that is used to encrypt data.
3. When Alice sends her profile data to the server, Alice uses the shared secret encrypt the profile data. Alice also authenticates with her authentication key to verify it is her. This way only she can make changes.
4. When Bob views Alice's profile he uses his private DH key to decrypt the profile data.
5. The shared secret is recomputed for Alice and her friends every time Alice adds or removes a friend.

Issues:

• For the DH key arrangement, Alice and all her friends need to all do the computations before the key arrangement (shared secret) is set. This requires everyone to do computations with their private keys. This means they all need to be logged in.

[yungRoz]

I can draw this out later tonight if it would be easier <3

Idea 3 - DH-like key shared secret scheme:

1. Alice signsup/logs on, generates a public/private key pair to be stored in the browser with something like IndexedDb?
2. Alice edits content, content is encrypted with public key, and displayed on Alices browser via private key decryption.
3. Alice adds Bob, which causes Alices part of DH shared key (private key mixture) to be stored in a database friend table for Bob as Alice's friend.
4. Bob accepts the friend request, which causes Bobs part of the DH shared key to be stored in the database friend table for Alice as Bob's friend.
5. When Bob accepts, Bob's private key gets added to Alices part of the DH shared key. His browser then decrypts his content with his private key and encrypts it with the shared key and stores his new friendship encrypted content in the database for Alice to decrypt when she logs on.
6. The acceptance is understood by Alice's client, meaning a boolean in the friend table is altered.
7. When Alice logs on she will be able to see Bob's content by adding her private key to Bob's part of the DH shared key and decrypt.
8. Alice will then encrypt her content - in a similar manor as bob did in 5 - with the shared key and upload it to the database.
9. Anytime Bob wants to see Alice's content, his browser must import his private key and add it to her part of the shared key, which he has stored in the friend table, to decrypt her content.
10. If Bob doesn't accept the friend request the friend table is simply deleted.

[thegeophysicist]

Alice updates her profile.

[thegeophysicist]

Alice requests/views Bob's profile.

[tymc7]

Since we figured this out, should we close?

[thegeophysicist]

Yup!