Re: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems
On 5/10/17 3:55 AM, 共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU wrote: Hello, I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. But, there is not yet the machine for build, so I cannot do actual machine verification. The CPU is not Intel architecture, is probably z/Architecture. I want to know beforehand the appropriate command-line parameters for executing "Configure". Is it right to specify "linux64-s390x" as follows? (1)cd //openssl-1.0.2k (2)./Configure linux64-s390x Thanks in advance. Regards, Manabu I'd suggest just running "./config". That will pick the appropriate 64-bit target. Only use Configure if you want to do something non-standard. :) TOM -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SKM_ASN1_SET_OF_i2d
What’s the replacement for code that used SKM_ASN1_SET_OF_i2d in OpenSSL 1.1? The code I’ve got that calls this function is getting the DER encoding of a STACK_OF() as a sorted SET. This STACK_OF() is of a custom ASN1 type; and is a member of another structure that is also a custom ASN1 structure. The call looks like this: int len = SKM_ASN1_SET_OF_i2d(structureName, containingStructure->member, NULL, i2d_structureName, V_ASN1_SET, V_ASN1_UNIVERSAL, IS_SET);* “structureName” is the typedef’d name of the C struct, which was also passed to the DEFINE_STACK_OF() and DECLARE_ASN1_FUNCTIONS() macros (in OpenSSL < 1.1, it’s DECLARE_STACK_OF(), not DEFINE_STACK_OF() ). “containingStructure” is a pointer to a C struct, and its member, “member” is of the type, STACK_OF(structureName). Thanks! TOM * And later it’s called again with a valid pointer of size len instead of NULL for the third parameter, to actually obtain the DER encoding. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question about OpenSSL and FIPS 140-2 module
> On Aug 4, 2016, at 11:00 AM, o haya wrote: > > Hi, > > I've been tasked to look into FIPS 140-2 "compliance" for our systems, > overall, and I know that there's a "FIPS 140-2 module" for OpenSSL, that > needs to be built from source and then integrated into OpenSSL by building > OpenSSL with the FIPS module. > > The User guide goes into how to integrate the resulting OpenSSL(+FIPS module) > with applications, and also has an example of doing that. > > What I was wondering is: Does that mean that EVERY application that we want > to have use the OpenSSL(+FIPS module) would have be (slightly) modified and > then rebuilt from source? Potentially, yes. Some may already have such modifications. You can also find unofficial patches for some packages to do this, too. Of course, that doesn’t help you with software that uses some other cryptographic software. You’d probably need to make massive changes to them. :) > What about something like Apache? Would we have to modify the Apache source > and rebuild that together with the OpenSSL(+FIPS module)? I believe there are already patches to make apache work with OpenSSL & FIPS. > Finally, what about COTS products, e.g., WebLogic, for which we cannot obtain > the source? You would need to ask your vendors about products that provide FIPS compliance. I really should point out three things, though: 1) FIPS 140 compliance (from any software package) is always less secure than non-FIPS 140 compliant packages. By its nature, the validation process places software several months to years out of date, and no changes are allowed, even to address severe security problems. There are known security problems in at least some of the OpenSSL FIPS modules. 2) FIPS 140 compliance is _not_ about security. It’s about proving that specific algorithms are in use, for purposes of government auditing. Nothing in the compliance tests actually prove that, either. The algorithms must simply be able to produce the correct output for well-known inputs (that includes several runtime tests that also only prove it gives the right output for well-known inputs), and there must exist some sort of “proof” that the module has not been modified from the tested form. There’s nothing in there to prevent FIPS 140 validation of a module that stores all your keys and sends them to someone else, and there’s nothing in there to prevent FIPS 140 validation of a module that contains algorithms that only do the right thing for those well-known inputs. There are even approved algorithms that have been shown to be insecure, even when the software implements the algorithm correctly (see Dual EC DRBG). 3) Unless you’re required by regulation to have FIPS 140 compliance, you should avoid it like the plague it is. It’s less secure, and you’ll never be able to update your software in a timely manner (even if there were no security problems, which is unlikely). Given that you reference COTS instead of GOTS, I suspect you’re not working for a government agency that is required to comply with FIPS 140. Steve Marquess has some excellent posts on his blog about these issues. Here’s one: http://veridicalsystems.com/blog/secure-or-compliant-pick-one/ TOM > Thanks, > Jim > -- > 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
Re: [openssl-users] FIPS: using libcrypto.so ?
> On Aug 2, 2016, at 1:59 PM, jonetsu wrote: > > The current FIPS User Guide mentions: > > "3.3 Creation of Shared Libraries > > The FIPS Object Module is not directly usable as a shared > library, but it can be linked into an application that is a > shared library. A “FIPS compatible” OpenSSL distribution will > automatically incorporate an available FIPS Object Module into > the libcrypto shared library when built using the fips > option (see §4.2.3)." > > Does the first sentence mean that there should be an intermediate, user > created, .so that itself uses libcrypto.a ? I think you’re confusing the FIPS Object Module with libcrypto. You might also be confusing the libcrypto produced from your FIPS build, and the libcrypto produced by a FIPS capable OpenSSL. The former is what you get when you compile the software found in, e.g., openssl-fips-2.0.11.tar.gz, while the latter is produced when you compile from a regular OpenSSL release (e.g. openssl-1.0.2g.tar.gz). These are three different things. The libcrypto from the FIPS build isn’t used in any of your link steps. The FIPS Object Module may be (and on most systems is) compiled as a shared object (not a .so file, but a shared object). Because it’s not a library, you can’t simply link it. Some systems allow shared objects to be accessed via dlopen(), and the warning is to indicate that doing so is inappropriate, even when it’s possible. Noting that you can link it into a shared executable or library indicates that if you have a shared library or executable that you want to link the FIPS Object Module into, that you may do so. The usual way to do this is to link libcrypto.a (from a FIPS capable OpenSSL build) and use the fipsld script. Even if you don’t do it the usual way (e.g. you want to link only the FIPS Object Module), then you may, but you still have to follow all the rules laid out in the security policy (e.g. do everything the fipsld script is doing). This probably not what one wants to do. It’s far more likely that one wants to use the FIPS capable OpenSSL shared library directly. That’s what the second part is about... > What does the second part mean ? The FOM will be included in the shared > library (assuming the libcrypto.so file) ? If so, then why wouldn't it be > available directly ? A clarification in perhaps simpler terms over what > seems to be an explanation in the User Guide would be much appreciated. It means that when you create a FIPS capable OpenSSL, if you compiled libcrypto as a shared library, that libcrypto shared library will incorporate the FIPS Object Module, following the security policy. This means that you can use that shared library as you would any other shared library, and still be able to enable FIPS mode. This is what most people who want to use a shared library will want to do. > In practical terms, is it possible for an application to link against a > libcrypto.so that provides all needed FIPS symbols ? In general, yes. In practice, it depends. Compiling a FIPS capable OpenSSL might not create a shared library on your system. In that case, you must link libcrypto.a, and use the fipsld script (or equivalent) when you link it. I think that the vast majority of systems will compile it as a shared library, though, without any intervention on your part. > If it's not, can you > give an example overview in which an application already using OpenSSL > (libcrypto.so) but now supporting FIPS, can still use libcrypto.so with full > FIPS support ? Just link against the library produced by the FIPS capable OpenSSL build. If, for some reason, that only produced libcrypto.a, then you need to investigate why — perhaps you passed “no-shared” when running the config script? > Is the only answer to now have the application linked > against libcrypto.a ? > > Thanks ! > > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > -- > 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
Re: [openssl-users] Custom Random number generation while in Fips mode
> On Jul 28, 2016, at 11:00 AM, pratyush parimal > wrote: > > Hi Thomas, > > Thanks for your response! It clears up matters a lot :) > > There's one thing that I thought of though -- even though I'm generating the > salt via non-OpenSSL means, the actual function that I'm using for hashing is > "SHA512" from FIPS OpenSSL. > Does the mere usage of salt that was generated via a non-FIPS-recommended > approach violate my compliance ? You used what is typically considered a cryptographic function (some form of RNG) from a source other than your cryptographic module running in approved mode. Unless you can fully justify that use as for non-cryptographic purposes, your product is not complying with FIPS 140. Given that it’s a salt for hashing passwords, I think you’ll have a really hard time convincing customers and auditors that the salt generation is for non-cryptographic purposes. After all, if that’s not cryptographic, why didn’t you use something more deterministic (like a counter, or a user name) for the salt? > I understand what you mean by "I'm not an auditor or a lawyer" , but I'd > still appreciate your opinion / experience in the matter :) In my limited experience, auditors are not computer security experts. They’re smart people, but they tend to fall back on very simple guidelines when it comes to things outside their own expertise (like what’s a cryptographic algorithm, and what’s a cryptographic purpose). You might be able to get away with it, but I wouldn’t want to stake a sale on it. Especially not if there are penalties attached for failing an audit. TOM > Thanks, > Pratyush. > > On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. > wrote: > > > On Jul 27, 2016, at 8:18 PM, pratyush parimal > > wrote: > > > > Hi all, > > > > I work on a consumer application which is striving to be fips-140-2 > > compliant. > > > > I'm using OpenSSL as recommended in the fips guide by invoking > > fips_mode_set(). However, in certain parts of the same application, I'm > > using my own non-OpenSSL random number generator to generate salts for > > hashing passwords for the app user accounts(I'm not using RAND_bytes). > > > > Does anyone know if using my custom random number generator in this way > > violates the app's fips compliance? > > That’s almost certainly a violation. There might be a few edge cases where > it is not, but they’re very unlikely. To determine if you’re even close to > such cases, ask: Does the RNG I’m using come from another FIPS 140 validated > cryptographic module? Am I using that module in approved mode? Am I using > that module according to its security policy? Do I have explicit permission > from the customers’ auditors to mix two modules in my product? > > If the answer to all of those questions is yes, you _might_ be OK, for now. > A few auditors (in the past, anyway) considered it OK to mix modules, while > other auditors say no. My own reading of FIPS 140-2 is that you may not mix > modules. But I’m not an auditor or a lawyer. :) > > The other question to ask is: can I clearly explain that the use of the > non-approved RNG is for non-cryptographic purposes, and easily justify that > explanation? Given what you said about why you’re using it, I’m pretty sure > the answer to that one is “no”. :) And even if you could, that’s still a > very weak argument to be making to your customers’ auditors, who may decide > it’s still not allowed even if they agree it’s for non-cryptographic purposes. > > > Am I really supposed to be using > > RAND_bytes for compliance reasons? > > Yes. > > > Thanks in advance! > > Pratyush. > > > > -- > > 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 > > -- > 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
Re: [openssl-users] Custom Random number generation while in Fips mode
> On Jul 27, 2016, at 8:18 PM, pratyush parimal > wrote: > > Hi all, > > I work on a consumer application which is striving to be fips-140-2 compliant. > > I'm using OpenSSL as recommended in the fips guide by invoking > fips_mode_set(). However, in certain parts of the same application, I'm using > my own non-OpenSSL random number generator to generate salts for hashing > passwords for the app user accounts(I'm not using RAND_bytes). > > Does anyone know if using my custom random number generator in this way > violates the app's fips compliance? That’s almost certainly a violation. There might be a few edge cases where it is not, but they’re very unlikely. To determine if you’re even close to such cases, ask: Does the RNG I’m using come from another FIPS 140 validated cryptographic module? Am I using that module in approved mode? Am I using that module according to its security policy? Do I have explicit permission from the customers’ auditors to mix two modules in my product? If the answer to all of those questions is yes, you _might_ be OK, for now. A few auditors (in the past, anyway) considered it OK to mix modules, while other auditors say no. My own reading of FIPS 140-2 is that you may not mix modules. But I’m not an auditor or a lawyer. :) The other question to ask is: can I clearly explain that the use of the non-approved RNG is for non-cryptographic purposes, and easily justify that explanation? Given what you said about why you’re using it, I’m pretty sure the answer to that one is “no”. :) And even if you could, that’s still a very weak argument to be making to your customers’ auditors, who may decide it’s still not allowed even if they agree it’s for non-cryptographic purposes. > Am I really supposed to be using > RAND_bytes for compliance reasons? Yes. > Thanks in advance! > Pratyush. > > -- > 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
Re: [openssl-users] CMS: Encrypt with binary encoding
> On Jun 22, 2016, at 11:40 AM, c.hol...@ades.at wrote: > > Yes, but then there is no MIME-Header. > Can I have MIME with binary encoding?? Not really. If you’re using raw binary output, the output wouldn’t be a MIME body (or body-part), so a MIME header would be inappropriate. MIME requires output to be 7-bit clean (i.e., the high bit of every byte is 0), with some special exceptions. Base64 is usually the preferred encoding, although many other encodings (e.g. uuencode) are allowed. Raw binary output would not be allowed (unless you could guarantee it meets the exceptional cases, which you can’t for something like this). You could always prepend a MIME header, but that wouldn’t make your output a MIME body. TOM -- +-+----+ | Thomas Francis, Jr. |Preserve wildlife --| | thomas.francis...@pobox.com | Pickle a squirrel! | | http://www.bbsclient.net/ || +-++ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] missing symbolic links under include directory
> On Apr 21, 2016, at 3:06 AM, Tim Culhane wrote: > > Hi all, > > My company makes calls to functions in the openssl source and thus includes > header files defined in the openssl library. > > Typically these header files were gathered together in a simgle place, under > include/openssl by way of symbolic links to the real header file locations. > > At present I'm updating the version of openssl our products used from 1.0.1g > to 1.0.2g, the latest stable release. > > I noticed that when I unpacked the source code for openssl 1.0.2g that there > were no symbolic links under the include/openssl directory. > > These were present in versions of openssl as late as 1.0.1q. > From looking through the mailing list archive, I believe this was a > deliberate change in how openssl is packaged. Is this correct? > > It appears that the configure or config script now needs to be run followed > by make depend in order to regenerate the symbolic links. You must run the configure script (and possibly make depend) to get the links created properly. My understanding is the deliberate change was more in the way of correcting archives that were made incorrectly; you’ve always (at least as long as I’ve been using OpenSSL, which has been almost 20 years) had to do this. It’s worth noting that configuring openssl will remove all of those links before creating them again, too, so as far as the symlinks go, having them around isn’t too bad, it’s just extra work. > My issue is that our products check out the openssl source from a local git > repository and the products build on both linux and sparc. > > Therefore, if I commit the latest openssl source code to our git repository > it must already contain the symbolic links required. Why? You should not keep installed headers in source control — you should use a binary repository (and keep the binaries and headers together) instead. OR, see below... > If I run config or configure followed by make depend before committing the > source code to git, will I be generating any operating specific files or > code? Yes. What’s worse is that if you commit all the files, when you try to configure OpenSSL on the second platform, it’ll tell you that it’s already been configured for the first platform and stop. > In other words, if I do config on sparc followed by make depend and then > commit the source to git, would there be any issues when I later checked out > the > files from git and built them on linux? Again, yes, there will be problems. If you want to build OpenSSL out of your source control on a regular basis, you should store the source files exactly as they exist in the tarball. Remove those headers from your source control — you don’t need them in order to build; they’re just wasting space in your source control. :) This means that each time you pull the code from source control, you configure and build the code as normal (which I assume you’re already doing — if not, OpenSSL probably isn’t working as it’s supposed to be working). If you don’t want to build OpenSSL all the time (and unless you maintain your own patches, I strongly recommend against building it all the time), then don’t keep it under source control at all. Keep it in some kind of binary repository which you update only when you need to upgrade OpenSSL (or add a patch, a new platform, etc). Then use that for deploying OpenSSL to your build systems as needed (presumably only once per build system). If you use some kind of system imaging to spin up new VMs for building, then make sure the OpenSSL installation is part of that system, so it gets installed with the new VM, not as part of your build process. That has the additional benefit of reducing your build times. :) If you need to have multiple versions of OpenSSL installed, simply configure each version to be installed to a different location (and install them to different locations), and adjust your other builds to look for the version they want in the version-specific location. That has the additional benefit of making it clear to everyone what version of OpenSSL is used by what build. TOM -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Info about size
> On Mar 21, 2016, at 10:23 AM, Alfonso Coscione wrote: > > Hi OpenSSL Staff, > > sorry for disturb. > I'm an italian young engineer and I'm working on new software project > that wuold want to use yours openssl library to realize an > encryption/decryption protocol to use for downloading updates from a > server. > I try to find on web some informations, but i'm not able to understand > about the sizes. > I explain better. > I've to know, more exactly, how to calculate the dimension of an > encrypted text after an encryption with a private key with an RSA > protocol.. Well, with RSA, the input size and output size will match the size of your key. For example, if you have a 2048-bit RSA key, then the output and input sizes must be exactly 2048 bits. You can encrypt/decrypt multiple times, in order to get larger amounts of data, but that’s almost certainly not what you want to do. Instead, you should choose a symmetric cipher (e.g. AES) for encrypting your data. You can then encrypt the symmetric key with your RSA key (along with appropriate padding, since your symmetric key should be smaller than your RSA key — there’s lots of good advice on the 'net for choosing appropriate sizes for these). It next depends on the algorithm you chose. If a streaming cipher, the input and output sizes will be the same. If a block cipher (like AES), it depends then on which mode you choose for predicting the size of your encrypted output. If you chose CBC, e.g., the output size will be a multiple of the block size, either the size of your plaintext rounded up to the nearest multiple of block size, or the size of your plaintext + the block size. For AEAD modes, like GCM, the output size will match your input size, but you’ll also have an additional value to store. Then, on top of all that, you probably need to include the encrypted key, so the receiving end can decrypt. Finally, I would note that you probably want to include some kind of structure around all this. CMS might serve you very well. At the least, it’s a good, relatively easy starting point. > and so, also the dimension of a decrypted text after an > decryption with a public key. > I don't know if you can help me.. I would appreciate any help or > suggestion. It depends on how you decide to format your data, but when this information is critical, but not likely to tell an attacker anything useful, one would usually just store the size of the decrypted data, so the receiver can just read it directly. However, it’s often not critical to know the size before you start decrypting, and a successful decryption will not return any excess data (such as padding), so you can track the size as you decrypt, and know as soon as it’s finished. Just to be sure it’s clear, but you usually don’t want to encrypt data with the private key — doing so means that just anyone can decrypt it. You want to encrypt using the public key, so that only the person who has the private key can decrypt it. And if you’re doing some sort of update, this kind of encryption is probably a bad idea, unless you’re encrypting updates for each customer. Unless there’s something super-super-secret about the update, I’d recommend delivering the update via TLS, and only sign the data, so that each customer has the public key, and only you have the private key, and each customer can be certain the update came from you, not some malicious user or system (and if it is that secret, I’d consider delivering updates only in person, and you can just avoid any automation entirely :) ). When creating signatures, you do encrypt with the private key, but we don’t usually use that terminology, in order to avoid confusion. When signing data, you would typically route all the data through a hash method (e.g. SHA-256), and encrypt the resulting hash along with info about the hash method to get a valid signature. Again, you’d need some structure to indicate what data was signed, and what the signature is, and again, CMS would be a good starting point. I think once you’ve decided exactly what you’ll be doing and how, you’ll be able to predict your final sizes. TOM -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests
> On Mar 2, 2016, at 12:27 PM, Neptune wrote: > > Using OpenSSL 1.0.1l > > I just learned the painful way that OpenSSL_add_all_digests() is not a > thread-safe function. I had been calling this in the constructor of a class > providing hash functions for multiple threads. My question is, how do I know > if a thread instantiating my class has called OpenSSL_add_all_digests() or > not? Is there a way to query OpenSSL for the state of the table? Perhaps > more importantly, is it a requirement to call this function at all? My test > application seems quite happy to do SHA1 hashes without calling any of the > *add_all* functions :-/ You should initialize OpenSSL prior to starting any threads. Likewise, you should then de-initialize it only after all threads (except your main thread, of course) have finished. If you absolutely have to do it inside some secondary thread, then initialize a value to tell you if you’ve initialized OpenSSL or not and look at it. If you’re using pthreads, you could put your OpenSSL initialization in a single function, and then in each thread, invoke it with pthread_once(). That way it’ll never be called more than once. That still leaves you with the issue of cleanup, but that might not matter, depending on how you use it. This is changing with OpenSSL 1.1, but for the better. IIUC, most users won’t need to bother with initialization at all. > Google searches bring back about a dozen different "proper" ways of > initializing, so I am asking for some expert guidance. A lot of the differences come down to personal preference. You don’t have to call OpenSSL_add_all_digests(), depending on what you’re doing, but I’d recommend either calling it, or calling EVP_add_digest() for each digest you intend to use. I’d also suggest that if it’s working without either call, then perhaps you’re not doing it right. :) Avoid using any functions like SHA1_Init(); use EVP_DigestInit(), instead. The EVP interfaces are superior, especially when you eventually need to change which hashing algorithm to use. TOM > Thanks! > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > -- > 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
Re: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
> On Feb 4, 2016, at 10:13 AM, Lesley Kimmel wrote: > > All; > > I'm working with PosgreSQL in a DoD environment and am supposed to enforce > FIPS operation. PostgreSQL doesn't perform a call to FIP_mode_set() but does > provide a configuration item 'ssl_ciphers'. Is there more to FIPS_mode than I > am aware of or would it be functionally equivalent to simply set my ciphers > to something like 'FIPS:!aNULL:!eNULL’? Yes, there is more to it. From a technical standpoint, several “power-on self-tests” are supposed to be run in order for FIPS mode to be enabled. While my own experience is the DoD’s auditors are a lot looser with the rules than most, other people report the opposite, and even the looser ones I’ve been in contact with would never allow what you’re suggesting. You really need to be modifying PostgreSQL to invoke FIPS_mode_set(), and understand that there may be more to it than that. I haven’t looked in a long time, but there are conceivably runtime issues if you just add that single call. Also, depending on the auditor, you’d probably need to modify PostgreSQL’s documentation, too, so that it cannot in any way refer to non-approved algorithms as cryptography (except as allowed by relevant NIST publications, but I think SHA-1 is the only special case). That could be tricky, and it’s up to the you to prove it’s OK, and then to remove the references anyway if the auditor still doesn’t like it. :) > As a semi-related question, would a non-FIPS OpenSSL installation still > enforce the same cipher suites but just not be 'officially' validated? AFAIK, you could limit it to the appropriate cipher suites, but be aware that FIPS 140 is all about proving that only certain known and tested [implementations of] algorithms are used. It’s unlikely that another version of OpenSSL would use exactly the same implementations (after all, fixes and performance enhancements have been added), and there’d still be nothing to prove those are the approved algorithms, even if they were the exact same. So I can’t imagine any auditor approving such a setup. OpenSSL doesn’t provide a cheap, easy answer to the issues surrounding FIPS 140 compliance, but it does significantly reduce the cost of effort for those producing software. For those who rely on third-party software, it still helps, but it’s usually going to be a lot more effort than just “add the OpenSSL FIPS module” to the system. :) TOM > Thanks! > -LJK > ___ > 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
Re: undefined reference to "FIPS_mode_set'
You need to compile the FIPS module and then a version of OpenSSL that uses that module. See https://www.openssl.org/docs/fips/UserGuide.pdf for links to appropriate documentation, depending on which version of the FIPS module you need to use (probably the latest one if you don't know you need the 1.0 module). Finally, after you've done that, you need to make sure your application is linking the OpenSSL library(ies) that you just compiled for FIPS mode, and not whatever was distributed with the OS. If you don't really need FIPS mode (or don't know why you need FIPS mode), though, don't call FIPS_mode_set(). :) TOM -- Original Message -- From: "Kay Shamsa" To: "openssl-users@openssl.org" Sent: 7/7/2014 8:30:16 PM Subject: undefined reference to "FIPS_mode_set' Hi; I am using encryption to broadcast messages in Linux environment. When using FIPS_mode_set(1) I get the error message of undefined reference to "FIPS_mode_set'. How can I fix this error. Thanks Kay --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
