Sosthene
93ae65ece7
Update pairing test
2024-11-12 18:02:41 +01:00
Sosthene
2463b8f05b
Update api
2024-11-12 18:02:32 +01:00
Sosthene
494270b636
Clean up connect.rs test
2024-11-12 18:02:32 +01:00
Sosthene
124718a207
Update pairing.rs documentation
2024-10-31 15:54:24 +01:00
Omar Oughriss
30d7ddcf1a
pairing.rs documentation
2024-10-31 14:58:30 +01:00
Sosthene
e9421f2e04
Fix connect.rs documentation
2024-10-30 16:06:52 +01:00
Omar Oughriss
bfa60aa023
Doc connect.rs
2024-10-30 15:26:08 +01:00
Sosthene
0a81ce12df
[tests/pairing] Replace create_update_transaction with *message
2024-10-30 15:10:33 +01:00
Sosthene
7ba532cebe
[tests/pairing] Add Alice and Bob secrets store
2024-10-30 15:09:27 +01:00
Sosthene
2910125bd1
Add connect logic
2024-10-29 12:55:02 +01:00
Sosthene
56cadb71f6
Remove CACHEDMESSAGES
2024-10-29 11:28:29 +01:00
078d2a0420
Ignore messages that are signed by ourselves
2024-10-17 14:30:09 +02:00
87113f5a34
Fix bug double mutex on processes
2024-10-17 14:29:39 +02:00
3372bcb1ed
Add is_linking() api
2024-10-17 14:28:58 +02:00
d7cd98ffe8
Fix bug, dont' send a cipher to ourselves when updating
2024-10-15 11:53:14 +02:00
4d04e50a65
Fix bug, continue to next prd if unsuccessfully parsing pcd
2024-10-15 11:52:50 +02:00
Sosthene
8b65463cd3
Fix cipher parsing issue + refactoring
2024-10-14 13:24:57 +02:00
Sosthene
caf620dd65
create_faucet_msg returns only the content not the Envelope
2024-10-13 01:12:16 +02:00
Sosthene
43b4c5f4d2
Broaded scope for the mutex when parsing ciphers
2024-10-13 01:11:52 +02:00
Sosthene
d121e8f7b2
Fix bug with processes mutex in process_transaction
2024-10-13 01:04:07 +02:00
Sosthene
0c5ddefc4b
Rm the shared_secrets from used messages
2024-10-12 22:54:39 +02:00
Sosthene
4b8d5c3611
Fix bug, parse_cipher keeps a cipher we can't decrypt
2024-10-12 22:39:40 +02:00
Sosthene
8ca4023d21
Fix bug with set_processes_cache
2024-10-12 22:35:55 +02:00
Sosthene
cae49617d5
Upgrade pairing
2024-10-10 16:55:36 +02:00
Sosthene
7c9eecab7a
Update api.rs for latest common dev
2024-10-07 11:22:54 +02:00
Sosthene
a592001fdb
Merge branch 'minimal_pcd_prd' into dev
2024-10-02 16:22:39 +02:00
Sosthene
6566f4c192
fix pairing tests
2024-09-27 15:13:23 +02:00
Sosthene
4bd1393306
fix pairing test
2024-09-27 12:44:10 +02:00
Sosthene
0dc14dee4a
create_update_transaction returns NewTxMessage
2024-09-26 10:45:01 +02:00
Sosthene
589e8d1d1d
Change new_tx return type to String
2024-09-25 17:06:27 +02:00
Sosthene
836f6cf900
Working pairing
2024-09-25 12:51:23 +02:00
Sosthene
1871dc9a5d
Import MutexExt trait from common
2024-09-23 12:44:20 +02:00
Sosthene
56558703c3
Add response logic
2024-09-23 12:33:32 +02:00
Sosthene
b904f4ec81
Process initial update
2024-09-21 19:42:27 +02:00
Sosthene
b7bffe7678
Add more error control
2024-09-02 14:45:35 +02:00
Sosthene
cf3278dd3d
Update process creation
2024-08-30 20:03:30 +02:00
Sosthene
287f74136e
Implement minimal prd/pcd, remove challenges
2024-08-30 20:03:30 +02:00
Sosthene
45628edb61
Add Process
2024-08-20 12:22:03 +02:00
Sosthene
d073b12340
Update tests
2024-08-15 16:19:29 +02:00
Sosthene
361a8aa409
Update api
2024-08-15 16:19:11 +02:00
Sosthene
b2cab53188
Break down parse_network_msg into parse_new_tx, parse_cipher
2024-08-14 09:45:19 +02:00
Sosthene
ec47592581
Update create_faucet_msg() to return the actual message to send
2024-08-13 14:28:19 +02:00
Sosthene
08aea30e2b
Rm data embedded in images
2024-08-12 05:28:52 +02:00
Sosthene
52382c96a1
All tests pass
2024-08-09 15:45:02 +02:00
Sosthene
9ce3918ff5
Add complete login test case
2024-08-09 11:58:46 +02:00
Sosthene
d82e145f50
working login
2024-08-01 12:26:26 +02:00
Sosthene
30759027b0
Refactor the whole api for the new 2fa model + various improvements
2024-07-19 23:12:11 +02:00
Sosthene
d737242bb5
New User creation
...
* Device is an unlogged user that is just able to scan incoming
transactions
* There's always a Device defined either we load one from indexedDB or
create one
* Logged users have a defined SPENDING_CLIENT that can sign transactions
* The pairing phase is when a new Device is created, we need another
Device to send it it's own spending key via normal 4nk messaging
* The new Device then encrypt it and send it back
* In another transaction, the first Device does the exact same thing
(probably possible to optimize)
* The logging phase is sending a 4nk message with the encrypted spending
key and getting the clear key back, basically logging with one device
of a pair is the same operation than pairing but in reverse
* Revokation output is an unique output for both devices, the validity
of the pair depends of it being unspent
* Revokation output is locked with some random key that both devices
will need to keep
* Todo: 1. implement the revokation scheme
2. optimize the pairing/logging flow
2024-07-11 12:41:23 +02:00
Sosthene
6f74996f39
Add wallet.rs
2024-07-11 12:39:25 +02:00
Sosthene
1e79dfd7f6
rm shamir from user
2024-07-11 12:34:02 +02:00
