> my mailbox is flooded with your openssl mails Yeah, those unexpected result can occur when you subscribe to a mailing list.
> I want to unsubscribe, please tell me how to go about it Check at the bottom of each message where it says: openssl-users mailing list To unsubscribe: ... Or, for the general instructions, http://lmgtfy.com/?q=how+to+unsubscribe+from+a+mailing+list On Tue, Mar 15, 2016 at 11:53 PM, <rajesh_seetha...@thbs.com> wrote: > I want to unsubscribe, please tell me how to go about it > > my mailbox is flooded with your openssl mails > > -----Original Message----- > From: openssl-users-requ...@openssl.org > Sent: Wednesday, March 16, 2016 9:18am > To: openssl-users@openssl.org > Subject: openssl-users Digest, Vol 16, Issue 26 > > Send openssl-users mailing list submissions to > openssl-users@openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-requ...@openssl.org > > You can reach the person managing the list at > openssl-users-ow...@openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: Verifying the sha1 of fipscanister.o with what is > embedded in libcrypto.so (Steve Marquess) > 2. Re: Verifying the sha1 of fipscanister.o with what is > embedded in libcrypto.so (Jeremy Farrell) > 3. Re: Verifying the sha1 of fipscanister.o with what is > embedded in libcrypto.so (Satya Das) > 4. Re: Verifying the sha1 of fipscanister.o with what is > embedded in libcrypto.so (Mike Mohr) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Mar 2016 19:05:34 -0400 > From: Steve Marquess <marqu...@openssl.com> > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: <56e8953e.30...@openssl.com> > Content-Type: text/plain; charset=windows-1252 > > On 03/15/2016 04:58 PM, Mike Mohr wrote: >> During the linking process, parts of fipscanister.o are removed >> (discarded) by the linker. Also, jumps and call instructions have their >> operands changed (addresses are filled in or relocation information is >> added) and the machine code is fundamentally altered. >> >> Imagine the linking process as something analogous to baking a cheese >> quiche with tomatoes. The can of tomatoes you use (i.e., the >> fipscanister.o file) is opened. The metal can is discarded along with >> any liquid inside the can. Then the tomatoes are placed into the quiche >> and baked. Melting cheese seeps into the tomatoes and the tomatoes are >> physically deformed and soften. At the end you have a delicious quiche. >> Can you get the original can of tomatoes back, in its unmodified form, >> at this point? Can you identify exactly which can of tomatoes was used >> to make this quiche, given only photos of all the cans prior to opening >> them? > > To a rough first approximation this is true for object code, but the > story is a little more nuanced for the OpenSSL FIPS Object Module. We > create that in a way (the "monolithic" object module) that prevents the > application link process from scrambling what would otherwise have been > an assortment of object modules (in the software engineering sense, not > FIPS-speak). > > The premain (native compilation) process, the "incore" utilities > (cross-compilation), and the run-time POST integrity test all calculate > exactly the same digest over exactly the same bits (in our case, the > TEXT and RODATA segments). If the application link process rearranged > any of that TEXT or RODATA then the runtime integrity test would fail. > > So very technically speaking the FIPS module is not fipscanister.o, but > the TEXT and RODATA data within it. > > To use your analogy, the fipscanister.o "can" contains only one tomato > which is an indigestible and indivisible blob that appears intact in the > baked quiche. Bon App?tit.. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marqu...@openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > > > ------------------------------ > > Message: 2 > Date: Tue, 15 Mar 2016 23:37:21 +0000 > From: Jeremy Farrell <jeremy.farr...@oracle.com> > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: <56e89cb1.90...@oracle.com> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > On 15/03/2016 21:24, Satya Das wrote: >> Even if a vendor letter is good for CMVP, how is the vendor supposed to know >> ? > > By remembering whether or not he followed the required procedure; it's > the only way for him to know. > >> I would say openssl should give such a tool so that vendor and the testing >> Lab can know such things. It is more than critical that the applications >> link to the intended crypto module. > > You miss the point. It is no more or less critical that 'the application > link to the intended crypto module' than countless other things. Many of > the other things cannot be checked by running a tool. How would a tool > check that the vendor had executed 'make' at the appropriate stage as > opposed to (say) '/usr/bin/make'? How would a tool check that the vendor > had got the original tar file from the OSF CD rather than by downloading it? > >> This convoluted and complex object module linking etc. with 207 page user >> guide is specific to openssl's approach to FIPS, and therefore should be >> addressed by the project. It should not come down to some vendor document >> written in good faith. > > How can it come down to anything else? What other possible means are > there for a customer to know that an OpenSSL-based product is FIPS 140-2 > validated? > > -- > J. J. Farrell > Not speaking for Oracle. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Wed, 16 Mar 2016 00:38:39 +0000 > From: Satya Das <sa...@attivonetworks.com> > To: "openssl-users@openssl.org" <openssl-users@openssl.org> > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: > > <bl2pr07mb24047327c36cffea5bc19beed7...@bl2pr07mb2404.namprd07.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Steve, > > How does one get a hold of the embedded signature in libcrypto.so ? > > Thanks > > -----Original Message----- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Steve Marquess > Sent: Tuesday, March 15, 2016 3:54 PM > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what > is embedded in libcrypto.so > > On 03/15/2016 05:24 PM, Satya Das wrote: >> Hello Steve, >> >> Even if a vendor letter is good for CMVP, how is the vendor supposed >> to know ? > > Ummm, because the vendor is the one who created the validated module. > Only that vendor can know for sure how the module was created, because the > FIPS 140-2 requirements have non-technical procedural elements (think of > those as ideological or spiritual elements). > > Note that in this context "vendor" refers to the entity that created the > validated module and submitted it for FIPS 140-2 validation. The company that > uses the FIPS module in their product is a "user", not a "vendor", with > respect to the validated module. > >> I would say openssl should give such a tool so that vendor and the >> testing Lab can know such things. It is more than critical that the >> applications link to the intended crypto module. This convoluted and >> complex object module linking etc. with 207 page user guide is >> specific to openssl's approach to FIPS, and therefore should be >> addressed by the project. It should not come down to some vendor >> document written in good faith. > > But it necessarily always comes down to a vendor document, for *any* > validated module, not just the OpenSSL FIPS module.. I've tried and failed > now several times to articulate why that is so and can't think of any new way > to present it, but it is simply not possible to do what you want; there is no > such thing as a magical pixie dust detector. We cannot make one; no one can. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marqu...@openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > Message: 4 > Date: Tue, 15 Mar 2016 20:48:36 -0700 > From: Mike Mohr <akih...@gmail.com> > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: > <CAJe-LUgN7ucT4St_L=ok_HHEDPYP+jqcVRiV3vLVS=buwus...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > There isn't necessarily any embedded signature in a shared object. In many > cases, there won't be one. If your shared object was built with a new > enough version of GCC, hasn't been fully stripped, and its note section has > not been removed during the build process, you can get a SHA-1 checksum > from the binary like this: > michael@osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so > > Displaying notes found at file offset 0x000001c8 with length 0x00000024: > Owner Data size Description > GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID > bitstring) > Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2 > > The GNU linker generates this value, but for the details of how it is > calculated you'd probably have to refer to the gcc source code. Depending > on what is being hashed, you may or may not be able to re-calculate that > value at a later time. > > Caveat emptor: the build id was likely not designed to prove that the > executable code is unmodified. Its stated goal is to identify repeatable > builds on the same host with the same tools. > > "As long as politics is the shadow cast on society by big business, the > attenuation of the shadow will not change the substance." > > Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6, > page 163). Carbondale, IL: Southern Illinois University Press. > > On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <sa...@attivonetworks.com> wrote: > >> Steve, >> >> How does one get a hold of the embedded signature in libcrypto.so ? >> >> Thanks >> >> -----Original Message----- >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Steve Marquess >> Sent: Tuesday, March 15, 2016 3:54 PM >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with >> what is embedded in libcrypto.so >> >> On 03/15/2016 05:24 PM, Satya Das wrote: >> > Hello Steve, >> > >> > Even if a vendor letter is good for CMVP, how is the vendor supposed >> > to know ? >> >> Ummm, because the vendor is the one who created the validated module. >> Only that vendor can know for sure how the module was created, because the >> FIPS 140-2 requirements have non-technical procedural elements (think of >> those as ideological or spiritual elements). >> >> Note that in this context "vendor" refers to the entity that created the >> validated module and submitted it for FIPS 140-2 validation. The company >> that uses the FIPS module in their product is a "user", not a "vendor", >> with respect to the validated module. >> >> > I would say openssl should give such a tool so that vendor and the >> > testing Lab can know such things. It is more than critical that the >> > applications link to the intended crypto module. This convoluted and >> > complex object module linking etc. with 207 page user guide is >> > specific to openssl's approach to FIPS, and therefore should be >> > addressed by the project. It should not come down to some vendor >> > document written in good faith. >> >> But it necessarily always comes down to a vendor document, for *any* >> validated module, not just the OpenSSL FIPS module. I've tried and failed >> now several times to articulate why that is so and can't think of any new >> way to present it, but it is simply not possible to do what you want; there >> is no such thing as a magical pixie dust detector. We cannot make one; no >> one can. >> >> -Steve M. >> >> -- >> Steve Marquess >> OpenSSL Validation Services, Inc. >> 1829 Mount Ephraim Road >> Adamstown, MD 21710 >> USA >> +1 877 673 6775 s/b >> +1 301 874 2571 direct >> marqu...@openssl.com >> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/1f301ce5/attachment.html> > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
