Via le nouvel éditeur:
> simulation rang 1
>> rang 2
test sur du texte dont le paragraphe fait plus de 72 caractères alors
que la longueur de la ligne est réglée Í 72.
Nouveau test de M.V. pour la bonne cause.
--
Gilbert
<https://maccafe-osx.pagesperso-orange.fr>
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne les annulations et remplacements d'o͹ ces tests sauvages. Il va y avoir une pause dans ces bricolages en attendant de mettre en œuvre cette sécurisation. Une question Í laquelle tu sauras (ou pas) répondre : - j'ai les Cancel-Lock et Cancel-Key suivants : Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCICancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>) -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne
les annulations et remplacements d'o͹ ces tests sauvages.
Il va y avoir une pause dans ces bricolages en attendant de mettre en
œuvre cette sécurisation.
Une question Í laquelle tu sauras (ou pas) répondre :
- j'ai les Cancel-Lock et Cancel-Key suivants :
Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCICancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY
Tu sais comment on retrouve le « secret » qui a été utilisé ?
(je fais référence ici Í la page que tu m'avais indiquée :
<https://www.bortzmeyer.org/8315.html>)
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne les annulations et remplacements d'o͹ ces tests sauvages. Il va y avoir une pause dans ces bricolages en attendant de mettre en œuvre cette sécurisation. Une question Í laquelle tu sauras (ou pas) répondre : - j'ai les Cancel-Lock et Cancel-Key suivants : Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCICancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>) -- Michel VAUQUOIS - <http://michelvauquois.fr>
yamo'
Salut, M.V. a écrit :
Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>)
Euh, je prends du paracetamol et je réponds 🤔😉 Plus sérieusement, je poserais la question sur les deux groupes dédiés avec suivi sur lecteur de news. Ou mieux en anglais sur news.software.nntp et/ou news.software.readers -- Stéphane
Salut,
M.V. a écrit :
Tu sais comment on retrouve le « secret » qui a été utilisé ?
(je fais référence ici Í la page que tu m'avais indiquée :
<https://www.bortzmeyer.org/8315.html>)
Euh, je prends du paracetamol et je réponds 🤔😉
Plus sérieusement, je poserais la question sur les deux groupes dédiés
avec suivi sur lecteur de news. Ou mieux en anglais sur news.software.nntp
et/ou news.software.readers
Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>)
Euh, je prends du paracetamol et je réponds 🤔😉 Plus sérieusement, je poserais la question sur les deux groupes dédiés avec suivi sur lecteur de news. Ou mieux en anglais sur news.software.nntp et/ou news.software.readers -- Stéphane
Michael Bäuerle
M.V. wrote:
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne les annulations et remplacements d'o͹ ces tests sauvages. Il va y avoir une pause dans ces bricolages en attendant de mettre en œuvre cette sécurisation. Une question Í laquelle tu sauras (ou pas) répondre : - j'ai les Cancel-Lock et Cancel-Key suivants : Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI> Cancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY> Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>)
I have used an online translator to read french and translate back: ============ Le secret (appelé « sec » dans RFC 8315) ne doit pas être révélé avec le champ d’en-tête « Cancel-Key », si l’algorithme recommandé de la section 4 est utilisé. Mais le secret n’est pas requis pour l’opération de vérification. Il suffit de calculer le hachage et de comparer. OpenSSL peut être utilisé : | | $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64 | RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY ou l’utilitaire canlock du paquet libcanlock: | | $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY=' | Good ============ Original english version for reference: The secret (called "sec" in RFC 8315) should not be revealed with the "Cancel-Key" header field, if the recommended algorithm from Section 4 is used. But the secret is not required for the check operation. It is sufficient to calculate the hash and compare. OpenSSL can be used: | | $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64 | RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY or the canlock utility from the libcanlock package: | | $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY=' | Good
M.V. wrote:
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
>
> Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne
les annulations et remplacements d'o͹ ces tests sauvages.
Il va y avoir une pause dans ces bricolages en attendant de mettre en
œuvre cette sécurisation.
Une question Í laquelle tu sauras (ou pas) répondre :
- j'ai les Cancel-Lock et Cancel-Key suivants :
Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI> Cancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY>
Tu sais comment on retrouve le « secret » qui a été utilisé ?
(je fais référence ici Í la page que tu m'avais indiquée :
<https://www.bortzmeyer.org/8315.html>)
I have used an online translator to read french and translate back:
============ Le secret (appelé « sec » dans RFC 8315) ne doit pas être révélé avec
le champ d’en-tête « Cancel-Key », si l’algorithme recommandé de la
section 4 est utilisé.
Mais le secret n’est pas requis pour l’opération de vérification.
Il suffit de calculer le hachage et de comparer.
OpenSSL peut être utilisé :
|
| $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64
| RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY
ou l’utilitaire canlock du paquet libcanlock:
|
| $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY='
| Good
============ Original english version for reference:
The secret (called "sec" in RFC 8315) should not be revealed with the
"Cancel-Key" header field, if the recommended algorithm from Section 4
is used.
But the secret is not required for the check operation. It is sufficient
to calculate the hash and compare. OpenSSL can be used:
|
| $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64
| RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY
or the canlock utility from the libcanlock package:
|
| $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY='
| Good
Le 13 juin 2021 Í 09:48, yamo' s'est exprimé en ces termes :
Ça doit faire parti des tests (plus un troisième un peu différent)
Exactement. On essaye de sécuriser au maximum MacCafé en ce qui concerne les annulations et remplacements d'o͹ ces tests sauvages. Il va y avoir une pause dans ces bricolages en attendant de mettre en œuvre cette sécurisation. Une question Í laquelle tu sauras (ou pas) répondre : - j'ai les Cancel-Lock et Cancel-Key suivants : Cancel-Key : sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI> Cancel-Lock : sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY> Tu sais comment on retrouve le « secret » qui a été utilisé ? (je fais référence ici Í la page que tu m'avais indiquée : <https://www.bortzmeyer.org/8315.html>)
I have used an online translator to read french and translate back: ============ Le secret (appelé « sec » dans RFC 8315) ne doit pas être révélé avec le champ d’en-tête « Cancel-Key », si l’algorithme recommandé de la section 4 est utilisé. Mais le secret n’est pas requis pour l’opération de vérification. Il suffit de calculer le hachage et de comparer. OpenSSL peut être utilisé : | | $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64 | RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY ou l’utilitaire canlock du paquet libcanlock: | | $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY=' | Good ============ Original english version for reference: The secret (called "sec" in RFC 8315) should not be revealed with the "Cancel-Key" header field, if the recommended algorithm from Section 4 is used. But the secret is not required for the check operation. It is sufficient to calculate the hash and compare. OpenSSL can be used: | | $ printf "%s" 'RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=' | openssl dgst -sha256 -binary | openssl enc -base64 | RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY or the canlock utility from the libcanlock package: | | $ canlock -c 'sha256:RbxMLBmPuIBpOgstlAePiq3NFdrgSY3F4IBpmGCIbCI=','sha256:RYHNtGfvqohs6J4EBakJtP8rpzh/wi0ielMCJFw6dAY=' | Good
M.V.
Le 14 juin 2021 Í 19:57, Michael Bäuerle s'est exprimé en ces termes :
I have used an online translator to read french and translate back
Wouah ! Thanks for your efforts.
But the secret is not required for the check operation. It is sufficient to calculate the hash and compare. OpenSSL can be used
Yes, I know that, but in fact it's not my question… I want to know how someone can discover the secret with the couple Cancel-Lock / Cancel-Key. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 14 juin 2021 Í 19:57, Michael Bäuerle s'est exprimé en ces termes :
I have used an online translator to read french and translate back
Wouah ! Thanks for your efforts.
But the secret is not required for the check operation. It is sufficient
to calculate the hash and compare. OpenSSL can be used
Yes, I know that, but in fact it's not my question…
I want to know how someone can discover the secret with the couple
Cancel-Lock / Cancel-Key.
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 14 juin 2021 Í 19:57, Michael Bäuerle s'est exprimé en ces termes :
I have used an online translator to read french and translate back
Wouah ! Thanks for your efforts.
But the secret is not required for the check operation. It is sufficient to calculate the hash and compare. OpenSSL can be used
Yes, I know that, but in fact it's not my question… I want to know how someone can discover the secret with the couple Cancel-Lock / Cancel-Key. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Michael Bäuerle
M.V. wrote:
Le 14 juin 2021 Í 19:57, Michael Bäuerle s'est exprimé en ces termes :
But the secret is not required for the check operation. It is sufficient to calculate the hash and compare. OpenSSL can be used
Yes, I know that, but in fact it's not my question… I want to know how someone can discover the secret with the couple Cancel-Lock / Cancel-Key.
If the key "K" was calculated as recommended in Section 4, this requires to break the HMAC function.
M.V. wrote:
Le 14 juin 2021 Í 19:57, Michael Bäuerle s'est exprimé en ces termes :
>
> But the secret is not required for the check operation. It is sufficient
> to calculate the hash and compare. OpenSSL can be used
Yes, I know that, but in fact it's not my question…
I want to know how someone can discover the secret with the couple
Cancel-Lock / Cancel-Key.
If the key "K" was calculated as recommended in Section 4, this requires
to break the HMAC function.
Le 14 juin 2021 Í 23:41, Michael Bäuerle s'est exprimé en ces termes :
If the key "K" was calculated as recommended in Section 4, this requires to break the HMAC function.
Too tough for me ! Thanks. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Michael Bäuerle
M.V. wrote:
Le 14 juin 2021 Í 23:41, Michael Bäuerle s'est exprimé en ces termes :
If the key "K" was calculated as recommended in Section 4, this requires to break the HMAC function.
Too tough for me ! Thanks.
It is the major property of a secret that only the owner knows it. Calculating a secret from public data must therefore be difficult (ideally impossible). In our case a sender creates "sec", e.g. by storing a random number (and keeps it secret). It can then be used to create Cancel-Locks and Cancel-Keys. That nobody else knows the secret ensures that only the owner of the secret can create a matching Cancel-Key for a Cancel-Lock that was already published.
M.V. wrote:
Le 14 juin 2021 Í 23:41, Michael Bäuerle s'est exprimé en ces termes :
>
> If the key "K" was calculated as recommended in Section 4, this requires
> to break the HMAC function.
Too tough for me ! Thanks.
It is the major property of a secret that only the owner knows it.
Calculating a secret from public data must therefore be difficult
(ideally impossible).
In our case a sender creates "sec", e.g. by storing a random number
(and keeps it secret). It can then be used to create Cancel-Locks
and Cancel-Keys.
That nobody else knows the secret ensures that only the owner of the
secret can create a matching Cancel-Key for a Cancel-Lock that was
already published.
Le 14 juin 2021 Í 23:41, Michael Bäuerle s'est exprimé en ces termes :
If the key "K" was calculated as recommended in Section 4, this requires to break the HMAC function.
Too tough for me ! Thanks.
It is the major property of a secret that only the owner knows it. Calculating a secret from public data must therefore be difficult (ideally impossible). In our case a sender creates "sec", e.g. by storing a random number (and keeps it secret). It can then be used to create Cancel-Locks and Cancel-Keys. That nobody else knows the secret ensures that only the owner of the secret can create a matching Cancel-Key for a Cancel-Lock that was already published.
M.V.
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
Calculating a secret from public data must therefore be difficult (ideally impossible).
I read this (I'm sure you know this site ! ) : <https://www.bortzmeyer.org/8315.html> and I see : « La section 4 donne les détails sur le choix de la clé (du mot de passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle doit être Í usage unique puisque, une fois révélée par un Cancel-Key:, elle n'est plus secrète. » with Google Translation : « Section 4 gives details on choosing the key (password). Obviously, it must be difficult to guess, so rather chosen by a pseudo-random algorithm (and not "azerty123"). And it must be disposable since, once revealed by a Cancel-Key :, it is no longer secret. » « once revealed by a Cancel-Key :, it is no longer secret. » ! It's not as easy to discover the key as it's seems here ! -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
Calculating a secret from public data must therefore be difficult
(ideally impossible).
I read this (I'm sure you know this site ! ) :
<https://www.bortzmeyer.org/8315.html>
and I see :
« La section 4 donne les détails sur le choix de la clé (du mot de
passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t
choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle
doit être Í usage unique puisque, une fois révélée par un Cancel-Key:,
elle n'est plus secrète. »
with Google Translation :
« Section 4 gives details on choosing the key (password). Obviously, it
must be difficult to guess, so rather chosen by a pseudo-random
algorithm (and not "azerty123"). And it must be disposable since, once
revealed by a Cancel-Key :, it is no longer secret. »
« once revealed by a Cancel-Key :, it is no longer secret. » !
It's not as easy to discover the key as it's seems here !
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
Calculating a secret from public data must therefore be difficult (ideally impossible).
I read this (I'm sure you know this site ! ) : <https://www.bortzmeyer.org/8315.html> and I see : « La section 4 donne les détails sur le choix de la clé (du mot de passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle doit être Í usage unique puisque, une fois révélée par un Cancel-Key:, elle n'est plus secrète. » with Google Translation : « Section 4 gives details on choosing the key (password). Obviously, it must be difficult to guess, so rather chosen by a pseudo-random algorithm (and not "azerty123"). And it must be disposable since, once revealed by a Cancel-Key :, it is no longer secret. » « once revealed by a Cancel-Key :, it is no longer secret. » ! It's not as easy to discover the key as it's seems here ! -- Michel VAUQUOIS - <http://michelvauquois.fr>
Michael Bäuerle
M.V. wrote:
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
Calculating a secret from public data must therefore be difficult (ideally impossible).
I read this (I'm sure you know this site ! ) : <https://www.bortzmeyer.org/8315.html> and I see : « La section 4 donne les détails sur le choix de la clé (du mot de passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle doit être Í usage unique puisque, une fois révélée par un Cancel-Key:, elle n'est plus secrète. » with Google Translation : « Section 4 gives details on choosing the key (password). Obviously, it must be difficult to guess, so rather chosen by a pseudo-random algorithm (and not "azerty123"). And it must be disposable since, once revealed by a Cancel-Key :, it is no longer secret. » « once revealed by a Cancel-Key :, it is no longer secret. » ! It's not as easy to discover the key as it's seems here !
What is revealed in the "Cancel-Key" header field is the key "K", not the secret "sec" (in terms of RFC 8315). It is indeed possible to directly use "sec" as "K": K = sec But in this case, as you noted above, every "sec" can only be used once. The user must create a new "sec" for every Cancel-Lock and needs a database that can be used to retrieve the used pairs "mid"/"sec" to create a Cancel-Key later. Because this is inconvenient AFAIK no real world implementation uses this algorithm. The recommended algorithm from RFC 8315 [1] to calculate "K" is: K = HMAC(sec, uid+mid) If every user has its own "sec", the algorithm can be simplified to: K = HMAC(sec, mid) This allows to use the same "sec" multiple times. The HMAC function [2] must protect "sec" when "K" is revealed. With this algorithm no database is required. A Cancel-Key can be directly calculated with the (unchanged) secret "sec" and the target Message-ID "mid". Examples how this can be implemented for a newsreader: libcanlock [3] contains RFC 6234 HMAC code [4] (used e.g. by tin). flnews [5] uses OpenSSL for HMAC calculations [6]. Servers normally use implementations written in Perl [7]. ______________ [1] <https://datatracker.ietf.org/doc/html/rfc8315#section-4> [2] <https://en.wikipedia.org/wiki/HMAC> [3] <https://micha.freeshell.org/libcanlock/doc/man3/cl_get_key.3.html> [4] <https://datatracker.ietf.org/doc/html/rfc6234> [5] <https://micha.freeshell.org/flnews/doc/html/core_8c_source.html#l05417> [6] <https://micha.freeshell.org/flnews/doc/html/hmac_8c_source.html> (Code looks ugly because it should work with different OpenSSL APIs) [7] <https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html> (German)
M.V. wrote:
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
>
> Calculating a secret from public data must therefore be difficult
> (ideally impossible).
I read this (I'm sure you know this site ! ) :
<https://www.bortzmeyer.org/8315.html>
and I see :
« La section 4 donne les détails sur le choix de la clé (du mot de
passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t
choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle
doit être Í usage unique puisque, une fois révélée par un Cancel-Key:,
elle n'est plus secrète. »
with Google Translation :
« Section 4 gives details on choosing the key (password). Obviously, it
must be difficult to guess, so rather chosen by a pseudo-random
algorithm (and not "azerty123"). And it must be disposable since, once
revealed by a Cancel-Key :, it is no longer secret. »
« once revealed by a Cancel-Key :, it is no longer secret. » !
It's not as easy to discover the key as it's seems here !
What is revealed in the "Cancel-Key" header field is the key "K",
not the secret "sec" (in terms of RFC 8315).
It is indeed possible to directly use "sec" as "K":
K = sec
But in this case, as you noted above, every "sec" can only be used once.
The user must create a new "sec" for every Cancel-Lock and needs a
database that can be used to retrieve the used pairs "mid"/"sec" to
create a Cancel-Key later.
Because this is inconvenient AFAIK no real world implementation uses
this algorithm.
The recommended algorithm from RFC 8315 [1] to calculate "K" is:
K = HMAC(sec, uid+mid)
If every user has its own "sec", the algorithm can be simplified to:
K = HMAC(sec, mid)
This allows to use the same "sec" multiple times.
The HMAC function [2] must protect "sec" when "K" is revealed.
With this algorithm no database is required. A Cancel-Key can be
directly calculated with the (unchanged) secret "sec" and the target
Message-ID "mid".
Examples how this can be implemented for a newsreader:
libcanlock [3] contains RFC 6234 HMAC code [4] (used e.g. by tin).
flnews [5] uses OpenSSL for HMAC calculations [6].
Servers normally use implementations written in Perl [7].
______________
[1] <https://datatracker.ietf.org/doc/html/rfc8315#section-4>
[2] <https://en.wikipedia.org/wiki/HMAC>
[3] <https://micha.freeshell.org/libcanlock/doc/man3/cl_get_key.3.html>
[4] <https://datatracker.ietf.org/doc/html/rfc6234>
[5] <https://micha.freeshell.org/flnews/doc/html/core_8c_source.html#l05417>
[6] <https://micha.freeshell.org/flnews/doc/html/hmac_8c_source.html>
(Code looks ugly because it should work with different OpenSSL APIs)
[7] <https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html>
(German)
Le 15 juin 2021 Í 21:19, Michael Bäuerle s'est exprimé en ces termes :
Calculating a secret from public data must therefore be difficult (ideally impossible).
I read this (I'm sure you know this site ! ) : <https://www.bortzmeyer.org/8315.html> and I see : « La section 4 donne les détails sur le choix de la clé (du mot de passe). Évidemment, elle doit être difficile Í deviner, donc plutÍ´t choisie par un algorithme pseudo-aléatoire (et pas "azerty123"). Et elle doit être Í usage unique puisque, une fois révélée par un Cancel-Key:, elle n'est plus secrète. » with Google Translation : « Section 4 gives details on choosing the key (password). Obviously, it must be difficult to guess, so rather chosen by a pseudo-random algorithm (and not "azerty123"). And it must be disposable since, once revealed by a Cancel-Key :, it is no longer secret. » « once revealed by a Cancel-Key :, it is no longer secret. » ! It's not as easy to discover the key as it's seems here !
What is revealed in the "Cancel-Key" header field is the key "K", not the secret "sec" (in terms of RFC 8315). It is indeed possible to directly use "sec" as "K": K = sec But in this case, as you noted above, every "sec" can only be used once. The user must create a new "sec" for every Cancel-Lock and needs a database that can be used to retrieve the used pairs "mid"/"sec" to create a Cancel-Key later. Because this is inconvenient AFAIK no real world implementation uses this algorithm. The recommended algorithm from RFC 8315 [1] to calculate "K" is: K = HMAC(sec, uid+mid) If every user has its own "sec", the algorithm can be simplified to: K = HMAC(sec, mid) This allows to use the same "sec" multiple times. The HMAC function [2] must protect "sec" when "K" is revealed. With this algorithm no database is required. A Cancel-Key can be directly calculated with the (unchanged) secret "sec" and the target Message-ID "mid". Examples how this can be implemented for a newsreader: libcanlock [3] contains RFC 6234 HMAC code [4] (used e.g. by tin). flnews [5] uses OpenSSL for HMAC calculations [6]. Servers normally use implementations written in Perl [7]. ______________ [1] <https://datatracker.ietf.org/doc/html/rfc8315#section-4> [2] <https://en.wikipedia.org/wiki/HMAC> [3] <https://micha.freeshell.org/libcanlock/doc/man3/cl_get_key.3.html> [4] <https://datatracker.ietf.org/doc/html/rfc6234> [5] <https://micha.freeshell.org/flnews/doc/html/core_8c_source.html#l05417> [6] <https://micha.freeshell.org/flnews/doc/html/hmac_8c_source.html> (Code looks ugly because it should work with different OpenSSL APIs) [7] <https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html> (German)
M.V.
Le 16 juin 2021 Í 01:29, Michael Bäuerle s'est exprimé en ces termes :
What is revealed in the "Cancel-Key" header field is the key "K", not the secret "sec" (in terms of RFC 8315).
Thanks for your answer : the level is too high for me ! -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 16 juin 2021 Í 01:29, Michael Bäuerle s'est exprimé en ces termes :
What is revealed in the "Cancel-Key" header field is the key "K",
not the secret "sec" (in terms of RFC 8315).
Thanks for your answer : the level is too high for me !
--
Michel VAUQUOIS - <http://michelvauquois.fr>
