💾 Archived View for gmi.noulin.net › gitRepositories › sodiumTest › file › README.md.gmi captured on 2023-01-29 at 11:24:25. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-11-04)

-=-=-=-=-=-=-

sodiumTest

Log

Files

Refs

README

README.md (2215B)

     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 is valid when it connects.
    33 The clients can request the server public key, if the server public key is already know, it can send the first encrypted message directly.