kalix-systems / herald Goto Github PK
View Code? Open in Web Editor NEWPre-alpha end-to-end encrypted instant messenger.
License: GNU Affero General Public License v3.0
Pre-alpha end-to-end encrypted instant messenger.
License: GNU Affero General Public License v3.0
what queries can the user make? some obvious ones:
FetchKey(of: UserId, dev: DeviceId)
ValidKeys(of: UserId)
AllKeys(of: UserId)
Responses to these are fairly obvious, but I want to have a written spec in addition to the code.
I'm inclined to make this a UI detail rather than a persistent feature of a linear message history. If you have secrets worth hiding, then not having a record of having turned them on or off seems correct.
If we go this route, this can stay confined to libherald
, if we don't and make them persistent, then there are a number of questions I would like to have answered about how these are going to be handled (e.g., are these events searchable in the global message search).
it's currently ugly and terrible. mainline implementation is less ugly than the stupid
bin, but it's a ways behind.
Possible directions (not mutually exclusive):
neon
): This is preferable to WebAssembly for a number of reasons. neon
is fairly mature and makes heraldcore
functionality drivable from Node.PyO3
): We know from experience that this is easy, if a bit rough.heraldcore
's public Rust API more ergonomic: This is something that we should do anyway.rust_swig
): I'm not sure how mature or robust rust_swing
is, so this may not be the correct approach. jni-rs
may be a better solution for JVM languages.rlua
). It's unclear how many people would use this.This would decrease both the reliability and bandwidth load on the server. GC strategy for blocks can be slower than for keys, so that'll help as well.
basic premise:
users have associated public signing and KEM keys
the basic API of KEM is that you can, from a public key p
, create a random shared secret, ss
, alongside a ciphertext cs
, which when combined with a secret key s
can reconstruct the shared secret.
message format:
cs
from KEM public keyproposed KEM: ntruhps4096821
proposed sig: falcon-1024
for alpha
bryce's job
not for alpha
low-pri teams features
possible redesign needs around teams:
Right now you could destroy someone's entire interaction with our system by sending them a message that fails to parse. If that happens, we should probably ignore it rather than forcing people to delete their accounts.
proposed flow:
connection init:
device sends "registration" or "login"
login:
device sends server global id it wants to login with
server sends 32 random bytes `bs`
device signs random bytes with key of said global id
registration:
device sends userid it wants to register with
if userid is free:
server replies "OK"
device sends public key
server sends random bytes
device signs bytes
otherwise:
server replies "TAKEN"
GOTO registration
Probably worth doing eventually, though extremely low priority
There are a lot of open questions re how best to handle encrypted group chat. The basic issue is a tradeoff in simplicity vs efficiency. I'm going to outline a couple proposals below:
There are a couple variants on this, and I'm not happy about any of them.
The basic idea is that group chats are a client-side detail, the server is only there for pki + offline delivery.
This will reliably be terrible for large groups, and makes even pairwise conversations awkward because our multi-device plans don't involve shared keys between devices, so actually all chats are group chats.
There are partial solutions here, such as generating a new key to encrypt your plaintext, then allowing the server to fanout the plaintext to everyone you want to send to while you reencrypt the key individually for each of them, but this is awkward and terrible. Let's not do it.
Sender keys are a decent solution to this - for every group chat, each device is associated with its own ratchet, known to all other members of the group. This means you can have full server-side fanout, saving the client CPU time and bandwidth. But, to maintain forward security, this requires additional key-generation by every device every time any conversation is updated, which is far from ideal. Also, doing this in a naive way would be vulnerable to spoofing attacks - if Alice, Bob, and Carol are all in a group together, they all know Bob's symmetric key for that group, so Alice could pretend to send messages as Bob.
Each channel is associated with its own blockchain. Hear me out, this is less stupid than it sounds. Each blockchain starts with some root shared-secret, and proceeds by proof-of-knowledge (I'll explain more below). Each block in this chain consists of:
a) A random N
-byte nonce (where N
is probably 32, but could be as low as 8)
b) The H
-byte hash of a previous block, B
(where H
is probably 32 and shouldn't be lower than 16)
c) The generation of the current block, equal to B.c
d) The current length of the chain, equal to B.d + 1
e) A signature by a member of the group of (a, b, c, d)
f) Ciphertext of the intended message, encrypted in aead-fashion, where the associated data is (a,b,c,d)
and the key is generated by kdf(a, B.b)
.
Every so often the chain restarts from a new random key that is sent via client-side fanout to preserve the self-healing properties of double ratchet. This also increments the generation of the new block, and contains the hash of a block in the previous generation.
Devices prefer to add new messages to the longest chain they currently know of, where any chain in a newer generation is longer than a chain in a previous generation.
Eventually blocks should be deleted, though exactly when to do this is not clear. It's probably safe to do so once every device has ack'd a downstream block, but that's not super clear to me.
It should definitely be safe to delete all blocks in generation g
after everyone has ack'd a block in generation g+1
.
See #47. Again, I want clarity about whether these are persistent features of the linear message history, and whether or not they expire like normal messages
This is a general issue for UI tasks which anyone can grab and implement.
Configuration Menu
Description : Add a gear icon button on the first toolbar in the contacts pane. Upon clicking this icon should launch a configuration popup with options for.
Chat View
*moved to sprint 2 electric boogaloo
Side Bar
Contact Chat Selection
Description : Clicking on a contact in the contact section should open a chatview with the relevant conversationID or UserID.
Visual Scaling Improvements
Refactors
Polish
This Issue is for problems related to code cleanliness and sanitization. Currently we have no automated linter or checker for QML sanity. So we will just play it by eye. We should try to keep
Main.qml
Paul: no complaints
ChatView.qml and Subcomponents
Paul: thinking of complaints
SideBar.qml and Subcomponents
Paul: long declarative non visual components such as pop ups should be moved to separate files.
Should make it essentially impossible for Eve to infer metadata without breaking TLS.
Desired behavior: upon renaming a contact, the name at the top of the chatview, in the chatbar should change iff you are in chatting with the renamed contact.
Current behavior: The name in the chatbar changes temporarily to the new name of any contact that has had its name edited.
Given the chainmail security model, it's pretty important that every device eventually receive every message that was sent to it. In order to do this, the server probably shouldn't delete messages until it's sure the client has received the message. Since file system writes can fail, I think we're going to want an ack on top of TCP after all.
Mobile adds desktop:
desktop: generate keypair, render public key to QR code
mobile: read QR code, sign public key, send signature to server
Desktop adds mobile:
desktop: generate keypair, sign public key, render keypair and signature to QR code
mobile: read QR code, check signature, write keys to disk, register with server
I expect we'll end up using these crates for QR-code stuff:
for example:
serde_cbor
to limit maximum memory allocationI'm not sure how best to pick these limits, so for now I'm going to leave TODO's in the code that reference this issue.
(probably partial) list of places in the code where this needs to be fixed:
read_cbor
send_cbor
serde_cbor
internals?We have been following a heuristic to decide which functionality belongs in heraldcore, but I think it's worth discussing what exactly each sub-project is for. My understanding was that herald_common was mostly to keep type definitions in sync between the client and server, but there seem to be a number of types (such as the message status enums) that are only of interest to the client.
Should we create a page on the wiki documenting project scope?
this list is not complete
Things to do:
Contacts
Messages
Things that are borked:
current api levels are at 28, this is rather exclusive. we know we can't go below 21, but the minimum possible api level is unknown. the symbols missing from 21 are __chk_poll and getrandom.
Running list of features we want now or eventually or maybe (everyone shld add stuff)
Wants:
Maybe:
steps to reproduce.
all messages will disappear, and then reappear upon scrolling any amount. this is not desired behavior.
we should move some files into common qml so that mobile development is not redundant.
Currently, heraldcore uses the appropriate data directories on desktop platforms in the platform_dirs
module.
There are implementations for Android and iOS, but they are placeholders and currently just use whatever $PWD
Android and iOS happen to pass them. I believe there are well-defined (or at least, strongly suggested) application specific data directories on these platforms, but have not looked into exactly what they are.
We need them to be distinct from userid's in order to associate ratchet keys with (sender, conversation) pairs. This is probably going to change a bunch of things involving the DB, and then a few message types.
Baeo, assigning this to you since AFAIK client-side DB stuff is your wheelhouse. Reassign it if this isn't true.
random other notes:
Put your opinions below:
fuzzy search on contacts : substring is fine.
Messages : yes, and robust โ๏ธ
Panicking across ffi is undefined behavior. Since we almost certainly won't succeed in proving the code won't panic, we should just catch it.
Implementing the mobile ui from the existing wire frames and testing it on IOS simulator and android simulator. This should be done with platform switches in QT, and requires decoupling and rewriting a lot of the UI. this is almost an entirely separate project. Here is my suggested plan of attack.
we should at least have an LRU cache for FS operations
The bug can be observed in commits after 7c57ebd. It is likely not a performance issue, as removing the heftier parts of the deleteContact function in ContactClickedPopup.mjs did not solve any issues.
The bug that just won't die - now we're running into issues because we might end up reusing a (key,nonce) pair due to network outages. This happens because when we mark the pending message as used, we end up having no unused keys in the store.
Should be fairly easy to fix without even touching chainmail, but at this point I'm noticing enough footguns in that API that I'm likely to change it as well.
User settings:
Conversation settings (all sync to everyone in convo at time of change):
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.