Ce sujet a été résolu
Non c'est M30w de Onche
Ceci, je fais pas de nofap c'est totalement débile
il y a 7 jours
Ceci, je fais pas de nofap c'est totalement débile
Croire au no fap alors que les vrais Alpha se vident les couilles 4 fois par jour
il y a 7 jours
toyawa
7j
tu tafs sur quoi
Une application web de messagerie cryptée E2EE (End-To-End-Encrypted), Forward secrecy par message (la compromission d'une clef ne compromet pas la confidentialité de l'ensemble de la discussion), le tout dans un backend Zero-Knowledge (le serveur ne reçoit jamais de clef privée, ni aucun élément permettant de déchiffrer les messages (simple relai de ciphertext), même sur demande légale, c'est techniquement impossible).
Authentification par identité cryptographique (paire ECDSA; envoie d'un nonce par le serveur, puis signature et vérif côté serveur via la clef publique ECDSA;) + authentification basique (username, password (hashé argon2i) si identité prouvée)
Chiffrement des messages AES-GCM via clef éphèmère basée sur ECDH+HKDF pour permettre aux parties de recalculer un secret partagé sans échanger les clefs privées.
Un message -> N ciphertexts (N dépend du nombre de destinataires)
Il y aura une app android, je développe l'API dans ce but. Pour l'instant je suis sur l'application web uniquement, en javascript via l'API WebCrypto, j'ai tout ce dont j'ai besoin; et je stocke les clefs privées dans le navigateur (IndexedDB) après chiffrement AES en dérivation PBKDF2 basée sur une passphrase définie par l'utilisateur à l'inscription, un salt et un iv, généré aléatoirement de façon crypto-secure)
Authentification par identité cryptographique (paire ECDSA; envoie d'un nonce par le serveur, puis signature et vérif côté serveur via la clef publique ECDSA;) + authentification basique (username, password (hashé argon2i) si identité prouvée)
Chiffrement des messages AES-GCM via clef éphèmère basée sur ECDH+HKDF pour permettre aux parties de recalculer un secret partagé sans échanger les clefs privées.
Un message -> N ciphertexts (N dépend du nombre de destinataires)
Il y aura une app android, je développe l'API dans ce but. Pour l'instant je suis sur l'application web uniquement, en javascript via l'API WebCrypto, j'ai tout ce dont j'ai besoin; et je stocke les clefs privées dans le navigateur (IndexedDB) après chiffrement AES en dérivation PBKDF2 basée sur une passphrase définie par l'utilisateur à l'inscription, un salt et un iv, généré aléatoirement de façon crypto-secure)
il y a 7 jours
Une application web de messagerie cryptée E2EE (End-To-End-Encrypted), Forward secrecy par message (la compromission d'une clef ne compromet pas la confidentialité de l'ensemble de la discussion), le tout dans un backend Zero-Knowledge (le serveur ne reçoit jamais de clef privée, ni aucun élément permettant de déchiffrer les messages (simple relai de ciphertext), même sur demande légale, c'est techniquement impossible).
Authentification par identité cryptographique (paire ECDSA; envoie d'un nonce par le serveur, puis signature et vérif côté serveur via la clef publique ECDSA;) + authentification basique (username, password (hashé argon2i) si identité prouvée)
Chiffrement des messages AES-GCM via clef éphèmère basée sur ECDH+HKDF pour permettre aux parties de recalculer un secret partagé sans échanger les clefs privées.
Un message -> N ciphertexts (N dépend du nombre de destinataires)
Il y aura une app android, je développe l'API dans ce but. Pour l'instant je suis sur l'application web uniquement, en javascript via l'API WebCrypto, j'ai tout ce dont j'ai besoin; et je stocke les clefs privées dans le navigateur (IndexedDB) après chiffrement AES en dérivation PBKDF2 basée sur une passphrase définie par l'utilisateur à l'inscription, un salt et un iv, généré aléatoirement de façon crypto-secure)
Authentification par identité cryptographique (paire ECDSA; envoie d'un nonce par le serveur, puis signature et vérif côté serveur via la clef publique ECDSA;) + authentification basique (username, password (hashé argon2i) si identité prouvée)
Chiffrement des messages AES-GCM via clef éphèmère basée sur ECDH+HKDF pour permettre aux parties de recalculer un secret partagé sans échanger les clefs privées.
Un message -> N ciphertexts (N dépend du nombre de destinataires)
Il y aura une app android, je développe l'API dans ce but. Pour l'instant je suis sur l'application web uniquement, en javascript via l'API WebCrypto, j'ai tout ce dont j'ai besoin; et je stocke les clefs privées dans le navigateur (IndexedDB) après chiffrement AES en dérivation PBKDF2 basée sur une passphrase définie par l'utilisateur à l'inscription, un salt et un iv, généré aléatoirement de façon crypto-secure)
j'ai pratiquement compris le principe de ton code grace à ma formation dev web que j'ai meme pas réussi à terminer c'est dingue,
sinon ouais ça doit etre chaud à taper j'en serai incapable, c'est l'ensemble de tout le fonctionnement ? ou bien juste le programme de l'interface qui renvoie sur l'api et ouvre ou non les autorisations sur le backend, c'est quand meme pas un prog de cryptage pour brouiller les infos en cas de fuite avec en plus une gestion de l'interface et demande de clé sur l'api avec controle et autorisation pour le démarrage sur le backend
sinon ouais ça doit etre chaud à taper j'en serai incapable, c'est l'ensemble de tout le fonctionnement ? ou bien juste le programme de l'interface qui renvoie sur l'api et ouvre ou non les autorisations sur le backend, c'est quand meme pas un prog de cryptage pour brouiller les infos en cas de fuite avec en plus une gestion de l'interface et demande de clé sur l'api avec controle et autorisation pour le démarrage sur le backend
il y a 7 jours
j'ai pratiquement compris le principe de ton code grace à ma formation dev web que j'ai meme pas réussi à terminer c'est dingue,
sinon ouais ça doit etre chaud à taper j'en serai incapable, c'est l'ensemble de tout le fonctionnement ? ou bien juste le programme de l'interface qui renvoie sur l'api et ouvre ou non les autorisations sur le backend, c'est quand meme pas un prog de cryptage pour brouiller les infos en cas de fuite avec en plus une gestion de l'interface et demande de clé sur l'api avec controle et autorisation pour le démarrage sur le backend
sinon ouais ça doit etre chaud à taper j'en serai incapable, c'est l'ensemble de tout le fonctionnement ? ou bien juste le programme de l'interface qui renvoie sur l'api et ouvre ou non les autorisations sur le backend, c'est quand meme pas un prog de cryptage pour brouiller les infos en cas de fuite avec en plus une gestion de l'interface et demande de clé sur l'api avec controle et autorisation pour le démarrage sur le backend
Backend django (python) + frontend js pur vanilla en utilisant l'API WebCrypto pour la cryptographie.
Le front-end contacte l'API interne du projet (parfois ex : envoi d'un message, demande de génération de challenge de signature).
Le client chiffre et détient les clefs privées, le serveur n'a que des clefs publiques, il ne peut techniquement rien déchiffrer.
J'ai fait un modèle entité-associations qui me sert de plan de base pour construire l'application, c'est un relai de ciphertext en fait, rien de très compliqué côté serveur, jute la logique de chiffrement côté client qui demande de l'attention.
Le front-end contacte l'API interne du projet (parfois ex : envoi d'un message, demande de génération de challenge de signature).
Le client chiffre et détient les clefs privées, le serveur n'a que des clefs publiques, il ne peut techniquement rien déchiffrer.
J'ai fait un modèle entité-associations qui me sert de plan de base pour construire l'application, c'est un relai de ciphertext en fait, rien de très compliqué côté serveur, jute la logique de chiffrement côté client qui demande de l'attention.
il y a 6 jours
En ligne
215
Sur ce sujet0










