InscriptionConnexion
Arrêtez
:Chatdoliprane:
:miaou:

il y a 7 jours
Arrêtez
:Chatdoliprane:
Es-tu Meow du serv no fap ?
:hippie:
il y a 7 jours
Es-tu Meow du serv no fap ?
:hippie:
Non c'est M30w de Onche
:CS_fleur:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
il y a 7 jours
Non c'est M30w de Onche
:CS_fleur:
Ceci, je fais pas de nofap c'est totalement débile
:Happycat:
:miaou:

il y a 7 jours
Ceci, je fais pas de nofap c'est totalement débile
:Happycat:
Croire au no fap alors que les vrais Alpha se vident les couilles 4 fois par jour
:philipheil:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
:sniffa:
il y a 7 jours
Vous continuez en plus
:-(


Qu'est-ce que je fais encore là ?
:(
:miaou:

il y a 7 jours
Vous continuez en plus
:-(


Qu'est-ce que je fais encore là ?
:(
va bosser
:Saitama_detendu_chouf_les_donzelle:
il y a 7 jours
va bosser
:Saitama_detendu_chouf_les_donzelle:
J'y vais.. à toute.
:miaou:

il y a 7 jours
tu tafs sur quoi
il y a 7 jours
Ouai Genre tu travaille
il y a 7 jours
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)
:miaou:

il y a 7 jours
Faites au moins semblant...
:hamtaro:
:miaou:

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)
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
:panache:
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
:panache:
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.
:miaou:

il y a 6 jours