> 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_seetharam at 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-request at openssl.org > Sent: Wednesday, March 16, 2016 9:18am > To: openssl-users at openssl.org > Subject: openssl-users Digest, Vol 16, Issue 26 > > Send openssl-users mailing list submissions to > openssl-users at 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-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at 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 <marquess at openssl.com> > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: <56E8953E.30100 at 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 > marquess at 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.farrell at oracle.com> > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: <56E89CB1.90700 at 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 <satya at attivonetworks.com> > To: "openssl-users at openssl.org" <openssl-users at openssl.org> > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > Message-ID: > <BL2PR07MB24047327C36CFFEA5BC19BEED78A0 at 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-bounces at openssl.org] On Behalf Of Steve Marquess > Sent: Tuesday, March 15, 2016 3:54 PM > To: openssl-users at 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 > marquess at 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 <akihana at gmail.com> > To: openssl-users at 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=buwUSSNg at 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 at 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 <satya at 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-bounces at openssl.org] On Behalf >> Of Steve Marquess >> Sent: Tuesday, March 15, 2016 3:54 PM >> To: openssl-users at 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 >> marquess at 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> >
