💾 Archived View for gmi.noulin.net › gitRepositories › sodiumTest › file › README.md.gmi captured on 2024-08-18 at 18:52:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
README.md (2498B)
1 # Libsodium
2 The programs in this repos depend on [sheepy](https://spartatek.se/r/sheepy/file/README.md.html) and [libsodium](https://libsodium.org).
3
4 ## sodiumTest
5
6 In `sodiumTest.c`, I implemented:
7 - public key cryptograpy
8 - public key signature, the message is signed the secret key and anyone can verify the signature with the public key
9 - one shot encryption with secret key. Usage: encrypt a file on disk
10 - derive key from password
11 - password hashing for storing in a server database
12
13 ## client.c and server.c
14 `client.c` and `server.c` are client and server using public key cryptograpy to exchange messages. This is a simple prototype which uses slow public key algorithms.
15
16 `client.c` and `client2.c` have more detail description of how the system works at the file top.
17
18 ## client2.c and server2.c
19
20 `client2.c` and `server2.c` implement a request-response system which supports anonymous clients. The clients don't have to be known in advance by the server.
21 The system uses public keys for key exchange and secret keys are derived for symetric key cryptograpy. After the key exchange, the message are send and received using symetric key cryptograpy.
22 For each session, the server changes public key to avoid reusing the same key pair and prevent replay attacks. For more nonce randomness, the server provides the first nonce for the client in the key exchange when the session opens.
23 The server identity is verified in the client, the trust is established on first use (TOFU).
24 The client can have identity keys which are verified by the server when provided during the key exchange. The server should store the client public identity key and link it to a user.
25
26 I created `sel.c` to handle the various keys, there are functions that don't take keys as parameters, they use the keys stored in `sel.c` buffers.
27
28 ## `client3.c` and `server3.c`
29 The server keeps the same session keys and uses a bloom filter to detect when client are reusing session keys.
30
31 ## `client4.c` and `server4.c`
32 `server4.c` has the client public keys and if the client key is valid when it connects, it is authenticated.
33 The clients can request the server public key, if the server public key is already known, it can send the first encrypted message directly.
34
35 ## preshared* client and server
36 The preshared client/server use public encryption like `client.c` and `server.c`.
37 - there is no key exchange, the keys are preshared
38 - a timestamp (in udp version) is used to avoid replay attacks
39 - the nonces are not stored