Données Cesium plus, à quoi correspond exactement le hash?

Support Cesium
,
1

Dans la documentation de Cesium+ (Cesium+ pod – HTTP API), il est indiqué :

A profile document is a JSON document. Mandatory fields are:

  • title: user name (Lastanem, firstname…)
  • time: submission time, in seconds (UTC unixtime)
  • issuer: user public key
  • hash: hash of the JSON document (without fields hash and signature)
  • signature: signature of the JSON document (without fields hash and signature)

Mais à quoi correspond précisément le hash ?

  • le document JSON au format texte ?
  • quel ordre pour les champs ?
  • avec ou sans espaces ?

Ce n’est pas urgent et je pourrais chercher dans le code, mais c’est important de définir précisément ce qui est signé, de manière à ce que je ne perde pas la vérifiabilité des données en les important dans IPFS (même si je vais les importer sans vérification).

2

Peut-être que Jaklis reproduit ce hash : jaklis/cesiumCommon.py at master - jaklis - P2Git

1 Like
3

oui c’est fait ici par exemple:

https://git.p2p.legal/axiom-team/jaklis/src/branch/master/lib/profiles.py#L8-L43

et

https://git.p2p.legal/axiom-team/jaklis/src/branch/master/lib/cesiumCommon.py#L37-L51

Donc pour répondre à tes questions, en format JSON texte sans esapce (dumps).
Au niveau de l’ordre, il me semble que Cs+ s’en fou et arrive à reconnaitre le hash peu importe l’ordre si j’ai bien compris, mais je ne sais pas comment il fait.

Dans mes datapods j’ai besoin de définir un ordre précis (celui implémenté).

hm

https://git.p2p.legal/axiom-team/jaklis/src/branch/master/lib/gvaID.py#L75

4

Il n’y a pas de tri des champs, ni de traitement des espaces. C’est le hash du document tel quel, serialisé comme tu veux. Ensuite, les pod CS+ ne doivent pas changer une virgule, un ordre, ou un espace où retour a la ligne.

L’avantage est de ne dépendre d’aucun protocole de formatage particulier. Donc accessible dans librairie JSON particulière.
L’inconvénient est qu’il faut stocker le document tel quel, ce que permet ES en natif. J’ai profité de cela.

Le hash et la signature sont simplement retiré du document serialisé, par regexp, pour faire la vérification

1 Like
5
oups

Je tente de reproduire ceci.

  1. je récupère un profil au format texte brut : https://g1.data.e-is.pro/user/profile/38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE
  2. je retire les champs “hash” et “signature”: "hash":"CFF2E187298BC9CEAA6457A1385A7A53A03BD173B69304316F9EBBC2E6625F5C","signature":"Xo0Cf5opgtT3bcZAGFCIs1/wD7NE2+mlr51QIZgcYGFte6Pc6i7CQBNU/PRFAo56+yaPjIHggK43JGFWHw6TBQ==",
  3. je calcule le hash du reste shasum profile
  4. je tombe sur un autre résultat : aa06ff9281ec4618c656221925606a4777536c11

Dans le code, je ne trouve pas plus précis que readAndVerifyIssuerSignature cesium-plus-pod-core/src/main/java/org/duniter/elasticsearch/service/AbstractService.java · master · clients / Cesium-grp / cesium-plus-pod · GitLab

Peux-tu confirmer :

  • comment récupérer un profil intact
  • comment retirer les champs hash et signature de la même manière que la vérification C+ pod
  • quel algorithme de hachage est utilisé précisément (et pourquoi signer un hash plutôt que le document ?)

Parce que je veux bien mettre les profils intacts dans les datapods, mais ce serait mieux si je pouvais m’assurer qu’ils sont vraiment intacts.

J’avais juste oublié de retirer l’en-tête de la réponse :

  1. je récupère un profil au format texte brut : https://g1.data.e-is.pro/user/profile/38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE
  2. je prends uniquement le champ “_source”
  3. je retire les champs “hash” et “signature”: "hash":"CFF2E187298BC9CEAA6457A1385A7A53A03BD173B69304316F9EBBC2E6625F5C","signature":"Xo0Cf5opgtT3bcZAGFCIs1/wD7NE2+mlr51QIZgcYGFte6Pc6i7CQBNU/PRFAo56+yaPjIHggK43JGFWHw6TBQ==",
  4. je calcule le hash du reste shasum -a 256 profile
  5. je tombe bien sur le résultat : cff2e187298bc9ceaa6457a1385a7a53a03bd173b69304316f9ebbc2e6625f5c

Il me reste à vérifier la signature mais ça devrait être bon.

Y a-t-il un moyen de récupérer la source au format brut sans l’en-tête ?

6

Oui bien sûr, essaie avec l’URL qui termine par /_source
(Après la pubkey)

Cf Doc d’elasticsearch (2.4 mais je ne penses pas que cela ai changé). Désolé je suis sur mon téléphone et ne peut pas vérifier

1 Like
7

Intéressant les recommandations pour conserver le champ _source : _source field | Elasticsearch Guide [8.13] | Elastic.

En fait la doc est plutôt claire, j’étais à côté de la plaque je pense : Search API | Elasticsearch Guide [8.13] | Elastic

On a maintenant les documents tels quels sur IPFS : https://bafybeiao6ugzahherdjtz2t7tak5iqhbeonr6d4xfljzblhxysz7xbp5gu.ipfs.pagu.re/

1 Like