Re: EVP_MAC_init - specify the hash algorithm
My mistake, it's EVP_MAC_fetch not EVP_MAC_new. The names are all case insensitive and are documented in the man7 pages: https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html and https://www.openssl.org/docs/man3.0/man7/EVP_MD-SHA2.html. The HMAC parameter names and types are also there: https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html Pauli On 10/9/21 9:07 am, Ken Goldman wrote: Where does one get the parameter values? E.g., where would I see the value strings for the EVP_MAC_new algorithm and the digest parameter values. I can guess HMAC and SHA256, but are they documented? Case sensitive? Which is preferred? You use EVP_MAC_new, which is undocumented. The doc sample uses EVP_MAC_fetch. Which is preferred? On 7/13/2021 7:06 PM, Dr Paul Dale wrote: Your code should look more like: OSSL_PARAMS params[2]; EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); EVP_MAC_free(mac); /* Now or later is all good and depends on the app reusing it or not */ params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0); params[1] = OSSL_PARAMS_construct_end(); EVP_MAC_init(mac_ctx, key, key_len, params); EVP_MAC_update(mac_ctx, data1, data1_len); EVP_MAC_update(mac_ctx, data2, data2_len); EVP_MAC_update(mac_ctx, data3, data3_len); EVP_MAC_final(mac_ctx, out, _size, out_len); EVP_MAC_CTX_free(mac_ctx);
Re: EVP_MAC_init - specify the hash algorithm
Where does one get the parameter values? E.g., where would I see the value strings for the EVP_MAC_new algorithm and the digest parameter values. I can guess HMAC and SHA256, but are they documented? Case sensitive? Which is preferred? You use EVP_MAC_new, which is undocumented. The doc sample uses EVP_MAC_fetch. Which is preferred? On 7/13/2021 7:06 PM, Dr Paul Dale wrote: Your code should look more like: OSSL_PARAMS params[2]; EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); EVP_MAC_free(mac); /* Now or later is all good and depends on the app reusing it or not */ params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0); params[1] = OSSL_PARAMS_construct_end(); EVP_MAC_init(mac_ctx, key, key_len, params); EVP_MAC_update(mac_ctx, data1, data1_len); EVP_MAC_update(mac_ctx, data2, data2_len); EVP_MAC_update(mac_ctx, data3, data3_len); EVP_MAC_final(mac_ctx, out, _size, out_len); EVP_MAC_CTX_free(mac_ctx);
Re: Congratulations! Missing 3.0.0 tag?
Randall S. Becker wrote in <015301d7a5be$22589940$6709cbc0$@nexbridge.com>: .. |cture" would have to reconstruct the Merkel Tree, which, even in SHA-1 \ Now you digress. But i had nothing to say from the start.. Good night! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
RE: Congratulations! Missing 3.0.0 tag?
On September 9, 2021 4:34 PM, Steffen Nurpmeso wrote: >Randall S. Becker wrote in > <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com>: > ... > >You are right in everything that you say. > > |Strictly speaking, the signature on a tag is considered immutable and \ > |transitively applies the signature to the commit (it does not >really, \ |but the effect is the same). The signature on a tag becomes >invalid \ > >The tag namespace is separate though. Not that it matters in practice. Just >saying. > > |if the underlying commit, or parents of that commit in git's Merkel \ |Tree > changes, so it is quite a strong signature. AFIAK, adding a >signature \ |to the commit itself does not really improve the strength of the >signing \ |(much), unless one implements a multi-signature >structure - like the \ |commit and signatures on three tags on the same >commit. You have then \ |implemented a three-signature >authority, which basically is a Blockchain\ |-style authority (not quite - I >used "-style"), providing that you \ |do trust the signers. I think >the word for that is "over-kill" , \ |but maybe not in the case of OpenSSL. > >Well. The thing is, to me, that commits happen much more often than tags. >Tags are in a different namespace also. "Sealing the >branches" with a signed commit at times helps in case of trouble, even for a >distributed version control system like git, with its "hardened >SHA-1" checksums. So of course all the core developers and a lot of other >people have full repo clones and shall someone break in some >infrastructure and mess around the OpenSSL team could simply talk and exchange >hashes, and reinstantiate the master proper. For >people having local clones that came in via git:// protocol even a signed >commit here and there would really be nice. (For my tiny things i >offer only https?, and "seal" all stable/ and release/ branches as well as >master, only the development branches have no signature.) The git signature structure is based on GPG signatures for one, not SHA-1. The tag namespace does not matter here. The signature becomes invalid if the combined tree of the commit the tag references changes. If the commit is replaced, the signature becomes invalid regardless of who does it. You can replace a signed commit with another signed commit but you would need to have the public side of the GPG key to validate it. A tag would not point to the new commit without breaking the signature. No one could replace Richard's signature, for example, except for Richard on the openssl-3.0.0 tag. The "breaking the infrastructure" would have to reconstruct the Merkel Tree, which, even in SHA-1 has a one in a billion chance of working, but that is unlikely to result in useful source code. So there is a certain amount of trust of the signatures of the committers - they should probably publish their public keys so we can do the validation. It might be helpful if GitHub moved to SHA-256 repositories, though.
Re: Congratulations! Missing 3.0.0 tag?
Randall S. Becker wrote in <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com>: ... You are right in everything that you say. |Strictly speaking, the signature on a tag is considered immutable and \ |transitively applies the signature to the commit (it does not really, \ |but the effect is the same). The signature on a tag becomes invalid \ The tag namespace is separate though. Not that it matters in practice. Just saying. |if the underlying commit, or parents of that commit in git's Merkel \ |Tree changes, so it is quite a strong signature. AFIAK, adding a signature \ |to the commit itself does not really improve the strength of the signing \ |(much), unless one implements a multi-signature structure - like the \ |commit and signatures on three tags on the same commit. You have then \ |implemented a three-signature authority, which basically is a Blockchain\ |-style authority (not quite - I used "-style"), providing that you \ |do trust the signers. I think the word for that is "over-kill" , \ |but maybe not in the case of OpenSSL. Well. The thing is, to me, that commits happen much more often than tags. Tags are in a different namespace also. "Sealing the branches" with a signed commit at times helps in case of trouble, even for a distributed version control system like git, with its "hardened SHA-1" checksums. So of course all the core developers and a lot of other people have full repo clones and shall someone break in some infrastructure and mess around the OpenSSL team could simply talk and exchange hashes, and reinstantiate the master proper. For people having local clones that came in via git:// protocol even a signed commit here and there would really be nice. (For my tiny things i offer only https?, and "seal" all stable/ and release/ branches as well as master, only the development branches have no signature.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
RE: Congratulations! Missing 3.0.0 tag?
On September 9, 2021 3:26 PM, Steffen Nurpmeso wrote: >To: Randall S. Becker >Cc: 'Benjamin Kaduk' ; openssl-users@openssl.org >Subject: Re: Congratulations! Missing 3.0.0 tag? > >Randall S. Becker wrote in > <012201d7a590$56df08d0$049d1a70$@nexbridge.com>: > |On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: > |>Benjamin Kaduk wrote in > |> <20210908233639.gy19...@akamai.com>: > |>|On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > ... > |>|I think (off the top of my head, i.e., without consulting a reference) \ > |>| |that `git log` (which your aliases end up at) will only >|display |>|signatures on commits, but will not show the tag objects >themselves. > |>|`git show` does display the tag object, and for openssl only the \ |>|tag > |object is what is signed; the commits themselves are not >|signed. > |> > |>I see. That is a logical one, thanks for the explanation. > ... > |$ git tag --verify openssl-3.0.0 > >Yes yes, ok! But like i said, wouldn't it be nice if at least release commits >would be signed also, a.k.a./or when a new branch is created? >In Linux for example the merge commits to the master branch are signed, in >addition to the tags of the actual releases. >It may even be a deja vu and i may have clamoured in the past. Strictly speaking, the signature on a tag is considered immutable and transitively applies the signature to the commit (it does not really, but the effect is the same). The signature on a tag becomes invalid if the underlying commit, or parents of that commit in git's Merkel Tree changes, so it is quite a strong signature. AFIAK, adding a signature to the commit itself does not really improve the strength of the signing (much), unless one implements a multi-signature structure - like the commit and signatures on three tags on the same commit. You have then implemented a three-signature authority, which basically is a Blockchain-style authority (not quite - I used "-style"), providing that you do trust the signers. I think the word for that is "over-kill" , but maybe not in the case of OpenSSL. -Randall
Re: Congratulations! Missing 3.0.0 tag?
Randall S. Becker wrote in <012201d7a590$56df08d0$049d1a70$@nexbridge.com>: |On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: |>Benjamin Kaduk wrote in |> <20210908233639.gy19...@akamai.com>: |>|On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: ... |>|I think (off the top of my head, i.e., without consulting a reference) \ |>| |that `git log` (which your aliases end up at) will only |display |>|signatures on commits, but will not show the tag objects themselves. |>|`git show` does display the tag object, and for openssl only the \ |>|tag |object is what is signed; the commits themselves are not |signed. |> |>I see. That is a logical one, thanks for the explanation. ... |$ git tag --verify openssl-3.0.0 Yes yes, ok! But like i said, wouldn't it be nice if at least release commits would be signed also, a.k.a./or when a new branch is created? In Linux for example the merge commits to the master branch are signed, in addition to the tags of the actual releases. It may even be a deja vu and i may have clamoured in the past. ... |Although I do not have Richard's public key on the system where I ran \ |the command and GitHub is not showing the verification status |of the tag. I do not know much about github. In fact i did not even know that the Linux release commits are _not_ signed, because if i look (what do _i_ know from the kernel?) then i only look at master, and there you see signed commits. And since my url= is https i do not actually verify tags. (In fact it is automated and simply diff(1)s in the difference to the version stated in the Makefile in /usr/src/linux/.) But true, the last merge before Linux 5.14 was signed, but the creation of the linux-5.14.y branch not. Ach, forget about the noise, i hope next time i finally have my head turned on before i post :) Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
RE: Congratulations! Missing 3.0.0 tag?
On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: >Benjamin Kaduk wrote in > <20210908233639.gy19...@akamai.com>: > |On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > |> But if i use > |> > |> #?0|kent:tls-openssl.git$ alias gl1 > |> alias gl1='git slpn -1' > |> #?0|kent:tls-openssl.git$ git alias|grep slpn > |> alias.slpn log --show-signature --patch --find-renames --stat --no-abbr\ > |> ev-commit > |> #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 > |> commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl\ > |> -3.0.0) > |> ... > |> > |> i do not. Hm, maybe i need to relearn git again, looking around |> i see > a couple of projects for which this is true (Linux, |> >wireguard-tools), for others it is not (my own project, nghttp2). > | > |I think (off the top of my head, i.e., without consulting a reference) > |that `git log` (which your aliases end up at) will only display >|signatures on commits, but will not show the tag objects themselves. > |`git show` does display the tag object, and for openssl only the tag > |object is what is signed; the commits themselves are not signed. > >I see. That is a logical one, thanks for the explanation. >Sometimes one (Me! That is.) really would have to drop all entrenched habits, >aliases and scripts and do anything anew. For example i >now have learned that "push" also can be signed! (And yes, i do use commit -S >and tag -s for release tags for .. many >years.) > > |-Ben > --End of <20210908233639.gy19...@akamai.com> > >--steffen $ git tag --verify openssl-3.0.0 object 89cd17a031e022211684eb7eb41190cf1910f9fa type commit tag openssl-3.0.0 tagger Richard Levitte 1631015200 +0200 OpenSSL 3.0.0 release tag gpg: Signature made Tue Sep 7 07:46:40 2021 EDT gpg:using DSA key A7AF9E78F709453B gpg: Can't check signature: public key not found Although I do not have Richard's public key on the system where I ran the command and GitHub is not showing the verification status of the tag. -Randall
RE: Congratulations! Missing 3.0.0 tag?
When git cloning, please remember that you might have to perform a git fetch --tags to pick up all tags from the upstream repository. After that, perform a git checkout openssl-3.0.0, which will give you a disconnected HEAD, but will refer to the correct release. You can always make your own branch to point there. Do not use the openssl-3.0 branch for building 3.0.0 – it already points to a new commit in the preparation for the subsequent release. Randall S. Becker, ITUGLIB Process Designer, Repository Manager, Occasional Porting Dude +1.416.984.9826 From: openssl-users On Behalf Of William Roberts Sent: September 8, 2021 5:39 PM To: openssl-users@openssl.org Subject: Re: Congratulations! Missing 3.0.0 tag? It's there: https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 I checked it out this morning. On Wed, Sep 8, 2021, 16:32 Steffen Nurpmeso mailto:stef...@sdaoden.eu> > wrote: Yeah? :) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Congratulations! Missing 3.0.0 tag?
Benjamin Kaduk wrote in <20210908233639.gy19...@akamai.com>: |On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: |> But if i use |> |> #?0|kent:tls-openssl.git$ alias gl1 |> alias gl1='git slpn -1' |> #?0|kent:tls-openssl.git$ git alias|grep slpn |> alias.slpn log --show-signature --patch --find-renames --stat --no-abbr\ |> ev-commit |> #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 |> commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl\ |> -3.0.0) |> ... |> |> i do not. Hm, maybe i need to relearn git again, looking around |> i see a couple of projects for which this is true (Linux, |> wireguard-tools), for others it is not (my own project, nghttp2). | |I think (off the top of my head, i.e., without consulting a reference) |that `git log` (which your aliases end up at) will only display |signatures on commits, but will not show the tag objects themselves. |`git show` does display the tag object, and for openssl only the tag |object is what is signed; the commits themselves are not signed. I see. That is a logical one, thanks for the explanation. Sometimes one (Me! That is.) really would have to drop all entrenched habits, aliases and scripts and do anything anew. For example i now have learned that "push" also can be signed! (And yes, i do use commit -S and tag -s for release tags for .. many years.) |-Ben --End of <20210908233639.gy19...@akamai.com> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)