Refactor technical report formatting and enhance clarity of server actions and cryptographic processes in the e-voting system documentation.
This commit is contained in:
E-Voting Developer
parent
3094b9f01b
commit
5933834627
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@ -1,6 +1,6 @@
|
||||
#set page(margin: (top: 2cm, bottom: 2cm, left: 2.5cm, right: 2.5cm))
|
||||
#set text(font: "New Computer Modern", size: 10pt, lang: "fr")
|
||||
#set heading(numbering: "1.1")
|
||||
#set heading(numbering: none)
|
||||
#show heading: it => {
|
||||
it
|
||||
v(0.3em)
|
||||
@ -190,14 +190,14 @@ Entrée : email, password, nom, prénom, CNI
|
||||
|
||||
Actions serveur :
|
||||
|
||||
1. Valider contraintes : email unique, password policy (8+ chars)
|
||||
2. Générer clés :
|
||||
- RSA 2048 (clé publique 294 bytes)
|
||||
- Dilithium ML-DSA-65 (clé publique 1312 bytes)
|
||||
- ElGamal (clés publique ~1024 bytes)
|
||||
- Kyber ML-KEM-768 (clé publique 1184 bytes)
|
||||
3. Hash password : bcrypt 12 rounds
|
||||
4. Stocker en BD : voter_id, email, password_hash, clés publiques
|
||||
- Valider contraintes : email unique, password policy (8+ chars)
|
||||
- Générer clés :
|
||||
- RSA 2048 (clé publique 294 bytes)
|
||||
- Dilithium ML-DSA-65 (clé publique 1312 bytes)
|
||||
- ElGamal (clés publique ~1024 bytes)
|
||||
- Kyber ML-KEM-768 (clé publique 1184 bytes)
|
||||
- Hash password : bcrypt 12 rounds
|
||||
- Stocker en BD : voter_id, email, password_hash, clés publiques
|
||||
|
||||
Résultat : JWT token + voter_id
|
||||
|
||||
@ -207,9 +207,9 @@ Entrée : email + password
|
||||
|
||||
Actions serveur :
|
||||
|
||||
1. Lookup voter par email
|
||||
2. bcrypt.verify(password)
|
||||
3. JWT.sign(payload={voter_id, exp=now+30min})
|
||||
- Lookup voter par email
|
||||
- bcrypt.verify(password)
|
||||
- JWT.sign(payload={voter_id, exp=now+30min})
|
||||
|
||||
JWT inclut : voter_id, timestamp d'expiration, signature HMAC-SHA256
|
||||
|
||||
@ -224,39 +224,39 @@ Chaque élection inclut : ID, nom, candidats, clés publiques
|
||||
|
||||
Processus cryptographique côté client :
|
||||
|
||||
1. Obtenir clés publiques élection (ElGamal, Kyber)
|
||||
- Obtenir clés publiques élection (ElGamal, Kyber)
|
||||
|
||||
2. Chiffrer candidate_id avec ElGamal :
|
||||
- Générer r aléatoire
|
||||
- (c1, c2) = (g^r mod p, candidate_id times h^r mod p)
|
||||
- Chiffrer candidate_id avec ElGamal :
|
||||
- Générer r aléatoire
|
||||
- (c1, c2) = (g^r mod p, candidate_id times h^r mod p)
|
||||
|
||||
3. Encapsuler clé avec Kyber :
|
||||
- kyber_ct, kyber_ss = Kyber.encap(kyber_pk)
|
||||
- Encapsuler clé avec Kyber :
|
||||
- kyber_ct, kyber_ss = Kyber.encap(kyber_pk)
|
||||
|
||||
4. Dériver clé symétrique hybride :
|
||||
- symmetric_key = SHA256(kyber_ss || c1 || c2)
|
||||
- Dériver clé symétrique hybride :
|
||||
- symmetric_key = SHA256(kyber_ss || c1 || c2)
|
||||
|
||||
5. Chiffrer vote avec AES-256-GCM :
|
||||
- vote_data = {election_id, (c1,c2), timestamp}
|
||||
- iv = random(12 bytes)
|
||||
- ciphertext = AES_GCM.encrypt(symmetric_key, iv, vote_data)
|
||||
- Chiffrer vote avec AES-256-GCM :
|
||||
- vote_data = {election_id, (c1,c2), timestamp}
|
||||
- iv = random(12 bytes)
|
||||
- ciphertext = AES_GCM.encrypt(symmetric_key, iv, vote_data)
|
||||
|
||||
6. Signer avec Dilithium :
|
||||
- sig_dilithium = Dilithium.sign(SHA256(ciphertext || iv))
|
||||
- Signer avec Dilithium :
|
||||
- sig_dilithium = Dilithium.sign(SHA256(ciphertext || iv))
|
||||
|
||||
7. Signer avec RSA-PSS 2048 :
|
||||
- sig_rsa = RSA_PSS.sign(SHA256(ciphertext || iv))
|
||||
- Signer avec RSA-PSS 2048 :
|
||||
- sig_rsa = RSA_PSS.sign(SHA256(ciphertext || iv))
|
||||
|
||||
8. Transmettre serveur : ciphertext, iv, signatures hybrides, kyber_ct
|
||||
- Transmettre serveur : ciphertext, iv, signatures hybrides, kyber_ct
|
||||
|
||||
Vérification serveur (6 étapes) :
|
||||
|
||||
1. Vérifier JWT (authenticité électeur)
|
||||
2. Vérifier non-double-vote (DB constraint)
|
||||
3. Vérifier signature Dilithium
|
||||
4. Vérifier signature RSA
|
||||
5. Déchiffrer avec clé privée Kyber serveur
|
||||
6. Enregistrer vote chiffré en BD
|
||||
- Vérifier JWT (authenticité électeur)
|
||||
- Vérifier non-double-vote (DB constraint)
|
||||
- Vérifier signature Dilithium
|
||||
- Vérifier signature RSA
|
||||
- Déchiffrer avec clé privée Kyber serveur
|
||||
- Enregistrer vote chiffré en BD
|
||||
|
||||
== 4.5 Phase 5 : Dépouillement
|
||||
|
||||
@ -281,10 +281,10 @@ Vérifier intégrité chaîne :
|
||||
|
||||
```
|
||||
Pour chaque bloc :
|
||||
1. Recalculer hash = SHA256(bloc)
|
||||
2. Vérifier hash correspond
|
||||
3. Vérifier prev_hash de bloc i = hash de bloc i-1
|
||||
4. Vérifier signature Dilithium du mineur
|
||||
Recalculer hash = SHA256(bloc)
|
||||
Vérifier hash correspond
|
||||
Vérifier prev_hash de bloc i = hash de bloc i-1
|
||||
Vérifier signature Dilithium du mineur
|
||||
|
||||
Si un vote modifié → hash change → chaîne invalide
|
||||
```
|
||||
@ -552,11 +552,11 @@ def tally_election(election_id, db):
|
||||
|
||||
7 services orchestrés :
|
||||
|
||||
1. MariaDB : Port 3306, volumes persistants
|
||||
2. Backend : Port 8000, dépend MariaDB
|
||||
3. Bootnode : Port 8546 (blockchain)
|
||||
4. Validator1/2/3 : Ports 8001/8002/8003
|
||||
5. Frontend : Port 3000, dépend Backend
|
||||
- MariaDB : Port 3306, volumes persistants
|
||||
- Backend : Port 8000, dépend MariaDB
|
||||
- Bootnode : Port 8546 (blockchain)
|
||||
- Validator1/2/3 : Ports 8001/8002/8003
|
||||
- Frontend : Port 3000, dépend Backend
|
||||
|
||||
Déploiement :
|
||||
```
|
||||
@ -597,21 +597,13 @@ Signature verification : Signature invalide → vote rejeté
|
||||
|
||||
== 9.1 Limitations Actuelles
|
||||
|
||||
1. Pas de Threshold Cryptography
|
||||
- Clé privée trésorier centralisée
|
||||
- Solution future : Shamir's Secret Sharing (k-of-n)
|
||||
- *Pas de Threshold Cryptography* : Clé privée trésorier centralisée. Solution future : Shamir's Secret Sharing (k-of-n)
|
||||
|
||||
2. PoA Simple
|
||||
- 3 validators seulement
|
||||
- Solution future : PoS / Hybrid consensus
|
||||
- *PoA Simple* : 3 validators seulement. Solution future : PoS / Hybrid consensus
|
||||
|
||||
3. Pas de Vérification Client Étendue
|
||||
- Vérification basique du chiffrement seulement
|
||||
- Impact : Serveur vérifie signature et format, mais pas contenu ballot
|
||||
- *Pas de Vérification Client Étendue* : Vérification basique du chiffrement seulement. Impact : Serveur vérifie signature et format, mais pas contenu ballot
|
||||
|
||||
4. Pas d'Attestation de Vote
|
||||
- Électeur ne reçoit pas récépissé vérifiable
|
||||
- Raison : Anonymat = impossible associer vote à électeur
|
||||
- *Pas d'Attestation de Vote* : Électeur ne reçoit pas récépissé vérifiable. Raison : Anonymat = impossible associer vote à électeur
|
||||
|
||||
== 9.2 Perspectives Futures (1-6 mois)
|
||||
|
||||
@ -650,9 +642,9 @@ Ce système de vote électronique démontre la faisabilité d'une architecture s
|
||||
|
||||
Contributions :
|
||||
|
||||
1. *Architecture complète* : Backend FastAPI + Frontend Next.js + Blockchain
|
||||
2. *Implémentation robuste* : 3000+ lignes cryptographie validée
|
||||
3. *Déploiement autonome* : Docker Compose reproductible
|
||||
4. *Documentation technique* : Rapport détaillé explications formelles
|
||||
- *Architecture complète* : Backend FastAPI + Frontend Next.js + Blockchain
|
||||
- *Implémentation robuste* : 3000+ lignes cryptographie validée
|
||||
- *Déploiement autonome* : Docker Compose reproductible
|
||||
- *Documentation technique* : Rapport détaillé explications formelles
|
||||
|
||||
Le système est production-ready pour prototype/test électoral. Déploiement réel nécessiterait audit sécurité indépendant et certification (CNIL/ANSSI).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user