Chiffrement des messages Cesium+

Thanks to @Spencer and @tuxmain, I just release a fonctionnal bash CLI for Cesium+/gchange messaging:

You can optionnaly edit your .env file with your data.

5 Likes

Wouah @poka et Spencer vous êtes chauds.

Je rêve d’une solution pour signer des contrats (en clair en tout ou partie) à plusieurs (2 ou plus).

1 Like

Ça c’est faisable, on entre le fichier à signer (un document PDF, ODT, texte…) ainsi que sa clé privée dans le programme, et il sort la signature. (déjà faisable facilement avec gnupg ou natools)

Il manque juste un système pratique pour lister et vérifier toutes les signatures dans un même fichier. Ce fichier pourrait être de la forme :

pubkey_base58 signature_base64
... (1 pubkey+signature par ligne)
3 Likes

Exactement

2 Likes

Yes, me too. On a related note, VERY important for users to understand what they’re signing… even if many don’t read in advance, at least we all know that we’re supposed to read/understand/truly-agree before we sign a contract. Im hoping to cover this topic eventually in my Spencer971 / learn-g1 · GitLab repo (at least for documents used by duniter) so that meticulous users can be aware of the contents in any document before they take that “critical” step of loading private-key material (whether: credentials/pubsec/ewif/shamir-shares) and adding their digital signature.

Citation tuxmain: (déjà faisable facilement avec gnupg ou natools)
and also tools / dubp-sign · GitLab

Citation tuxmain: Il manque juste un système pratique pour lister et vérifier toutes les signatures dans un même fichier. Ce fichier pourrait être de la forme :

pubkey_base58 signature_base64
... (1 pubkey+signature par ligne)

^^^ Which is consistent with existing standards.

Personally, I like the way (if I understand it correctly) that it’s done in duniter’s Transaction document… where the document itself holds the pubkeys (if we imply an enumerated list of the Issuers) and then imply a matching enumerated list of signatures at the bottom. Great for humans who read contracts they sign/verify… less so for programs perhaps.

-Spencer971

At least in the case for all tools related to this project… the tools should know that the pubkey is embedded as Issuer in the document itself… and safely assume that the bottom-signature must verify… so with good UI/UX (Im no good in that dept.) they’d be able to make it clear to users what it is they’re signing, and/or to re-assemble the document as signatures are added. To redundantly/wastefully include the pubkey prefixed on the signature seems acceptable to me for machine readability. -Spencer971

1 Like

J’ai le même problème que @poka :confused:
Je pense que je suis pas loin…

import * as g1lib from 'g1lib'
import nacl from 'tweetnacl'

const clean = await g1lib.crypto.idSecPass2cleanKeys(myId, myPassword)
const raw = await g1lib.crypto.idSecPass2rawAll(mYId, myPassword)

const message = {
  hash: 'F0FDF1F13B1247599D3D805A3D02DFF09DAAA9ECDCB47B74E67C3E9CBA1C0C29',
  signature:
    '9c+zhecWSdQ986bdWlPRYGyl/8HKbA3pJwhkk+L4RudmtTTHWHTZh9PSHkamYeEiX/CQawIH8Ulr8lmYzmVgBQ==',
  issuer: '2JggyyUn2puL5PG6jsMYFC2y9KwjjMmy2adnx3c5fUf8',
  recipient: '2JggyyUn2puL5PG6jsMYFC2y9KwjjMmy2adnx3c5fUf8',
  title: 'x/au9+x0mSdxhNkxmxSNcB4Q91Q=',
  content: '0kMYgPPFjt8KLnAeAJm/rx4U4EE=',
  time: 1642784107,
  nonce: '6nyiRmuPTnZEYL7nkqJ5qZbYJjX8gwf48',
  version: 2,
}
const ciphertext = g1lib.crypto.b64.decode(message.title)
const nonce = g1lib.crypto.b58.decode(message.nonce)
const senderPk = g1lib.crypto.b58.decode(message.issuer)
const recipientSk = g1lib.crypto.b58.decode(result.secretKey)

const decrypted = nacl.box.open(ciphertext, nonce, senderPk, recipientSk);

nacl renvoi l’erreur bad secret key size !
J’ai fouillé un vos codes, mais pfiouu, là je coince. J’ai essayé plein de chose…
Je ne sais pas trop pourquoi ça foire. Quelqu’un à une idée ?
Est-ce que tweetnacl^1.0.3 est compatible ? C’est bien box.open qu’il faut faire ?

@1000i100 Il n’y a pas accès à la lib tweetnacl depuis g1lib ? Je suis obligé de la charger en plus dans mon projet !

@ManUtopiK je ne souhaite pas l’exposer au travers de g1lib histoire d’éviter de faire un couplage qui empêcherait de changer de dépendance crypto si ça devenait pertinent. Ceci dit, ajouter à g1lib.crypto une fonction crypt(message, targetPubKey), sign(message, privateKey), uncrypt(cryptedMessage,privateKey), checkSign(message, issuerPubKey) me semble pertinant (quitte à ce que ce ne soit que des passe-plat pour tweetnacl).

Est-ce que ça répondrais au besoin ?

1 Like

Ok, c’est peut-être mieux comme ça de ne pas avoir accès à tweetnacl.
Pour les fonctions sur g1lib.crypto, ce serait vraiment top !

1 Like

Pour le nom des fonctions. Ce serait peut-être pas mal de s’inspirer de Encrypt & Decrypt Messages | polkadot{.js} pour se faciliter la tâche quand on migrera sur duniterv2s.

Je ne m’attendais pas à débusquer des complexité à autant d’endroit, mais je suis sur l’affaire. J’espère en voir le bout d’ici peu et pouvoir vous proposer dans g1lib une api simple pour des messages chiffrés.

4 Likes

chiffrement déchiffrement des messages cesium+ (et probablement gchange) livré dans g1lib v3.4.0

2 Likes