Re: Linking error on Soalris x86 and sparc using fips capable openssl 1.0.1h
Thanks all for the help. I could resolve both the errors: Sun-Intel : using -Wl, -Bsymbolic and resolving few other linking errors. Sun-sparc : Re-building libstdc++ all the errors gone away. Thanks again Andy for pointing it out. Regards, Mrunal On Mon, Sep 15, 2014 at 12:40 AM, Andy Polyakov wrote: > > While fips build on soalris, I am getting variour errors: > > > > Sun-Intel: > > > > FIPSLD_CC=gcc FIPSLD_LINK=g++ > > /unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/fipsld -fPIC > > -shared -g -O2 -o libImpl.so.10.0.0 -lcrypto > > Text relocation remains referenced > > against symbol offset in file > > fips_openssl_cpuid_setup0x1 > > > /unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o > > ld: fatal: relocations remain against allocatable but non-writable > sections > > collect2: ld returned 1 exit status > > > > after searching on net came to know that the option -fPIC should be used > > to fix this error and is used to build fipscanister.o as well as for the > > project where this is being used. > > FIPS module version 2 is compiled with -fPIC unconditionally. So > question is what is that about. I mean why did you need to do something? > > > Also read about using -Wl, -Bsymbolic, this removes above error, but > > fails for many other symbols. > > Such as? Essentially -Bsymbolic is a must for FIPS code. > > > Sun-sparc: > > > > For the above same linking on sparc, I got following error: > > 4280524028:error:25066067:DSO support routines:DLFCN_LOAD:could not load > > the shared > > > library:dso_dlfcn.c:187:filename(./objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0): > > ld.so.1: fips_premain_dso: fatal: relocation error: file > > ./objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0: symbol > > _ZNSt8__detail15_List_node_base7_M_hookEPS0_: referenced symbol not found > > 4280524028:error:25070067:DSO support routines:DSO_load:could not load > > the shared library:dso_lib.c:244: > > make: *** [objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0] Error 1 > > Looks like something for you to figure out, as the symbol in question > can't be from FIPS module. It seems to be something from libstdc++, so > question is if libImpl.so was linked with it and if so, why it can't be > found at that moment. > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-...@openssl.org > Automated List Manager majord...@openssl.org >
Re: SSL v3.0 is not set as default protocol upon disabling v2.
On 16 September 2014 23:01, Viktor Dukhovni wrote: > On Mon, Sep 15, 2014 at 11:19:52AM +0530, Thulasi Goriparthi wrote: > > > I suggest you try disabling TLS 1.0 along with SSL2 if you want to force > > your client to use SSL3 without changing the context's method. > > SSL_CTX_set_options(ctx, SSL_OP_ALL| > > SSL_OP_NO_SSLv2 | > > SSL_OP_NO_TLSv1); > > > > If the server supports TLS1.1 and TLS 1.2, update the client ctx option > to > > use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also. > > Actually, those additions are not needed. Because the TLS client > HELLO advertises a single contiguous range of supported protocols > (a mininum and maximum), once SSLv3 is enabled and TLSv1 is disabled, > that range consists of SSLv3 alone even when the client can support > TLSv1.1 and/or TLSv1.2. > Thanks. I didn't notice it before. > -- > Viktor. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Verifying authenticode signature using openssl API
On 16/09/2014 12:22, Prasad Dabak wrote: Hello, I am currently focusing on matching various digests that we talked about earlier in the thread. 1. Computing the hash of the executable (excluding the areas as defined by MS) and matching it with the value stored in spcIndirectData. This is straight forward and figured out. 2. Computing the hash of spcIndirectData and matching it with with "messageDigest" stored in AuthenticatedAttributes. I realized that the sequence and length bytes need to be skipped before computing the hash of the spcIndirectData? Is this documented anywhere? This is specified in the PKCS#7 standard (RFC2315), in particular, PKCS#7 specifies that when there is a non-empty contentInfo field in the PKCS#7 structure, which part of that should be hashed. In this case that contentInfo is a Microsoft-defiend spcIndirectData, but the calculation is unaffected. This should also be built in to the PKCS7 functions (I hope). 3. Computing hash of AuthenticatedAttributes and matching it with decrypted version of encryptedDigest. I am struggling to get this. Which portion of AuthenticatedAttributes should be considered for computing the hash? Further when I decrypt the encryptedDigest using the signer's public key, I get back a 256 byte value. This doesn't look like a SHA1 hash like in case (1) and (2). So what type of hash it is? Can someone elaborate OR point to documentation that elaborates on this? This is specified in the PKCS#7 standard (RFC2315). This should also be built in to the PKCS7 functions (I hope). By the way, the rules for checking the timestamp countersignature (but not its effect on checking the outer signature) is specified in RFC2985 section 5.3.6. The rules for parsing the SigningTime attribute used inside timestamp contersignatures (and elsewhere with less trust) are in RFC2985 section 5.3.3. On Sep 09, 2014, at 10:18 AM, Prasad Dabak wrote: Thanks Jacob for your response. Very informative indeed! Thanks -Prasad Sent from my iPhone > On 09-Sep-2014, at 10:05 pm, Jakob Bohm mailto:jb-open...@wisemo.com>> wrote: > >> On 09/09/2014 09:01, Prasad Dabak wrote: >> Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. > This time I have CC-ed you in addition to the mail list. >> I have a few follow-up questions on your response. >> >> 1. So, "encryptedDigest" has no relation to the stored "messageDigest"? I thought it's a encrypted version of the messageDigest? > As far as I recall, there is a chain of 4 digests. The first digest > is calculated over the file and is stored in the spcIndirectData. The > second digest is calculated over the spcIndirectData (the contentInfo > of the the PKCS#7 structure) and is stored as "messageDigest" in the > AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash > is calculated over the AuthenticatedAttributes and is signed to > produce the "encryptedDigest" in that same signerInfo. All 3 need to > be checked to confirm that the file hash is actually (indirectly) > signed by the encryptedDigest using the public key in the certificate > whose name is listed in the signerInfo. >> 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. > Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP > checksum of file). Also it is allowed to be 0 to indicate no checksum > (even if you set the checksum, it might be cleared if an Administrator > adds his own countersignature to all authorized programs on his > computers, aka AppLocker). >> 3. spcPEImageData is probably relevant only for signing that uses page hashes? > I never quite figured out where they store the page hashes. However I > believe the constant semi-empty spcPEImageData with the "<<>>" > string is the traditional marker to indicate that the signature is for > a PE file, and not e.g. a document file with the same hashed bytestream. > >> 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? > If it is, I am myself guessing a bit as to what that function does and > does not check. But note that it probably doesn't check the full chain > of 3 message digests, since at least the digest over the file itself is > inside a blob that the PKCS#7 standard has no opinion about. >> 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else h
Re: SSL v3.0 is not set as default protocol upon disabling v2.
On Mon, Sep 15, 2014 at 11:19:52AM +0530, Thulasi Goriparthi wrote: > I suggest you try disabling TLS 1.0 along with SSL2 if you want to force > your client to use SSL3 without changing the context's method. > SSL_CTX_set_options(ctx, SSL_OP_ALL| > SSL_OP_NO_SSLv2 | > SSL_OP_NO_TLSv1); > > If the server supports TLS1.1 and TLS 1.2, update the client ctx option to > use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also. Actually, those additions are not needed. Because the TLS client HELLO advertises a single contiguous range of supported protocols (a mininum and maximum), once SSLv3 is enabled and TLSv1 is disabled, that range consists of SSLv3 alone even when the client can support TLSv1.1 and/or TLSv1.2. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl FIPS compliance
On Sep 16, 2014, at 7:35 AM, T, Satyanarayana (GE Healthcare) wrote: > Hi, > > This is regarding FIPS support for openssl. I was able to build FIPS capable > Openssl and link it to my application which uses Openssl(AES-256) for > Database encryption. I enabled FIPS mode using FIPS_mode_set(1) (which did > passed) and ran some unit tests and I see that all of the current tests are > passing. > > From the openssl user guide I see that once I enabled FIPS mode using > FIPS_mode_set(1) all non-fips algorithms will be disabled. Having said that > since all my current tests are passing, Does that mean I am in FIPS compliant > for database encryption. It means you’re running OpenSSL in “FIPS mode”. What that means for compliance is something for your lawyers to determine. What you can do is pass along to the lawyers that you followed all of the rules set forth in the OpenSSL FIPS Security Guide (assuming you did), and that you’ve enabled FIPS mode. Let the lawyers worry about if that’s good enough or not — most of the time, it is, but just stating FIPS 140 compliance might not be correct. > Please do help me understand if I have to do anything else for enabling FIPS > mode…… Nope, from a technical perspective, as long as you followed the Security Guide (and using the exact steps in the FIPS User’s Guide is the best way to ensure that), the technical stuff is all done. :) TOM > Regards, > Satya. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL v3.0 is not set as default protocol upon disabling v2.
As Thulasi wrote, SSLv23_client_method supports *ALL* protocols that your library supports by default. The name of the function is just historical and should be ignored. From the documentation: "If the cipher list does not contain any SSLv2 ciphersuites (the default cipher list does not) or extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3." The real question is why the server that didn’t support TLS couldn’t fall back to SSLv3? If a SSLv3 server can’t understand a TLSv1 hello, then it kind of defeats the purpose of being able to fallback to SSLv3 ... Cheers! - John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On Sep 16, 2014, at 12:36 PM, abhijit pai wrote: Hi Thulasi, Thanks for the response. But my point is little different here. I have a generic HTTP client, that talks to SSL 3.0 as well as TLS 1.x enabled server. And as mentioned earlier, I have disabled SSLv2. Now, when I talk to any server, shouldn't the client be sending SSLv3(SSL 3.0) in the version instead of TLS 1.0 as seen from packet capture? Is it some default behaviour? Is it configurable? Regards, Abhijit > Thulasi Goriparthi > SSLv23_client_method supports all protocols by default and connects using > the highest protocol that server supports(as received from server hello) > > I suggest you try disabling TLS 1.0 along with SSL2 if you want to force > your client to use SSL3 without changing the context's method. > SSL_CTX_set_options(ctx, SSL_OP_ALL| > SSL_OP_NO_SSLv2 | > SSL_OP_NO_TLSv1); > > If the server supports TLS1.1 and TLS 1.2, update the client ctx option to > use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also. On Fri, Sep 12, 2014 at 6:01 PM, abhijit pai wrote: Hello All, I am using openSSL in my custom HTTP client. Here I use SSLv23_client_method() and disable SSLv2 using SSL_CTX_set_options(ctx, SSL_OP_ALL| SSL_OP_NO_SSLv2) I would expect the handshake method sent out to the server be SSL v3.0 but to my surprise it is TLS 1.0, which for some reasons the server does not support. This is a generic code, that would talk to even TLS 1.x enabled servers, so I cannot fix it using SSLv3_client_method(). Is there any other API that I am not aware of that could help me achieve it? Thanks in advance! Regards, Abhijit __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL v3.0 is not set as default protocol upon disabling v2.
Hi Thulasi, Thanks for the response. But my point is little different here. I have a generic HTTP client, that talks to SSL 3.0 as well as TLS 1.x enabled server. And as mentioned earlier, I have disabled SSLv2. Now, when I talk to any server, shouldn't the client be sending SSLv3(SSL 3.0) in the version instead of TLS 1.0 as seen from packet capture? Is it some default behaviour? Is it configurable? Regards, Abhijit > Thulasi Goriparthi > SSLv23_client_method supports all protocols by default and connects using > the highest protocol that server supports(as received from server hello) > > I suggest you try disabling TLS 1.0 along with SSL2 if you want to force > your client to use SSL3 without changing the context's method. > SSL_CTX_set_options(ctx, SSL_OP_ALL| > SSL_OP_NO_SSLv2 | > SSL_OP_NO_TLSv1); > > If the server supports TLS1.1 and TLS 1.2, update the client ctx option to > use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also. On Fri, Sep 12, 2014 at 6:01 PM, abhijit pai wrote: > Hello All, > > I am using openSSL in my custom HTTP client. > Here I use SSLv23_client_method() and disable SSLv2 using > SSL_CTX_set_options(ctx, SSL_OP_ALL| SSL_OP_NO_SSLv2) > > I would expect the handshake method sent out to the server be SSL v3.0 > but to my surprise it is TLS 1.0, which for some reasons the server > does not support. > > This is a generic code, that would talk to even TLS 1.x enabled > servers, so I cannot fix it using SSLv3_client_method(). > > Is there any other API that I am not aware of that could help me achieve > it? > > Thanks in advance! > > > Regards, > Abhijit >
Re: Certificate pass phrase brute force...
[SNIP] >> However this looks like the key is encrypted with 3DES, but I "exported" it >> from the Cert+Key with "-aes256" - so I'm puzzled why I'd have a 3DES >> encrypted p12. DT> You thought you did but you didn't. DT> The doc is a bit subtle, but the -$cipher option is listed under "PARSING". DT> It applies when *reading* a PKCS#12 and extracting the cert(s) and key(s?) DT> to separate files or sections, for (most) other OpenSSL operations, and DT> specifically to encrypting the extracted privatekey section. DT> To specify the PBE algorithm for the key when exporting *to PKCS12*, DT> use -keypbe, as listed on the man page under "EXPORTING". DT> And yes, it isn't very helpful that commandline doesn't warn when you DT> specify a combination of options that doesn't make sense. This is true DT> for most of the commandline functions historically, although a few that DT> have been (re)written recently are better. Ah, that makes sense. A little quibble - not with the answer but with the way the command line tool works. I probably paid less attention to the man page than I should have since it *looked* like in the pkcs12 utility "-aes256" was just like "-v2 aes256" in the pkcs8 utility - but as you state, it's not. As stated, the switch in one is an "input" to the cypher, but an "output" for the other. Gack! [It's probably too late to do something different in the PKCS12 tool, but changing the way the switches work to make the two sub-tools operate in a more consistent way might be a good goal.] I'd guess that, even if I had read the manpage more carefully, I'd never have reached the conclusion that -aes256 wasn't going to do what I wanted. [To me, it was just "obvious" what it did, and I would have never questioned that assumption even though it was obvious it wasn't working like I thought and I was "obviously" wrong!] This was the last piece I needed - I can put this thing to bed now. Thanks again to all for all your great help! -Greg
Openssl FIPS compliance
Hi,
This is regarding FIPS support for openssl. I was able to build FIPS capable
Openssl and link it to my application which uses Openssl(AES-256) for Database
encryption. I enabled FIPS mode using FIPS_mode_set(1) (which did passed) and
ran some unit tests and I see that all of the current tests are passing.
From the openssl user guide I see that once I enabled FIPS mode using
FIPS_mode_set(1) all non-fips algorithms will be disabled. Having said that
since all my current tests are passing, Does that mean I am in FIPS compliant
for database encryption.
Please do help me understand if I have to do anything else for enabling FIPS
mode..
Regards,
Satya.
:��I"Ϯ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
Re: Verifying authenticode signature using openssl API
Hello, I am currently focusing on matching various digests that we talked about earlier in the thread. 1. Computing the hash of the executable (excluding the areas as defined by MS) and matching it with the value stored in spcIndirectData. This is straight forward and figured out. 2. Computing the hash of spcIndirectData and matching it with with "messageDigest" stored in AuthenticatedAttributes. I realized that the sequence and length bytes need to be skipped before computing the hash of the spcIndirectData? Is this documented anywhere? 3. Computing hash of AuthenticatedAttributes and matching it with decrypted version of encryptedDigest. I am struggling to get this. Which portion of AuthenticatedAttributes should be considered for computing the hash? Further when I decrypt the encryptedDigest using the signer's public key, I get back a 256 byte value. This doesn't look like a SHA1 hash like in case (1) and (2). So what type of hash it is? Can someone elaborate OR point to documentation that elaborates on this? Thanks. -Prasad On Sep 09, 2014, at 10:18 AM, Prasad Dabak wrote: Thanks Jacob for your response. Very informative indeed! Thanks -Prasad Sent from my iPhone > On 09-Sep-2014, at 10:05 pm, Jakob Bohm wrote: > >> On 09/09/2014 09:01, Prasad Dabak wrote: >> Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. > This time I have CC-ed you in addition to the mail list. >> I have a few follow-up questions on your response. >> >> 1. So, "encryptedDigest" has no relation to the stored "messageDigest"? I thought it's a encrypted version of the messageDigest? > As far as I recall, there is a chain of 4 digests. The first digest > is calculated over the file and is stored in the spcIndirectData. The > second digest is calculated over the spcIndirectData (the contentInfo > of the the PKCS#7 structure) and is stored as "messageDigest" in the > AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash > is calculated over the AuthenticatedAttributes and is signed to > produce the "encryptedDigest" in that same signerInfo. All 3 need to > be checked to confirm that the file hash is actually (indirectly) > signed by the encryptedDigest using the public key in the certificate > whose name is listed in the signerInfo. >> 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. > Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP > checksum of file). Also it is allowed to be 0 to indicate no checksum > (even if you set the checksum, it might be cleared if an Administrator > adds his own countersignature to all authorized programs on his > computers, aka AppLocker). >> 3. spcPEImageData is probably relevant only for signing that uses page hashes? > I never quite figured out where they store the page hashes. However I > believe the constant semi-empty spcPEImageData with the "<< >>" > string is the traditional marker to indicate that the signature is for > a PE file, and not e.g. a document file with the same hashed bytestream. > >> 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? > If it is, I am myself guessing a bit as to what that function does and > does not check. But note that it probably doesn't check the full chain > of 3 message digests, since at least the digest over the file itself is > inside a blob that the PKCS#7 standard has no opinion about. >> 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate? > Actually, the subject is a data structure (a hierarchical list of sets > of tagged strings) and the relevant comparison would be to compare those > elements that don't change when getting a new certificate from the CA. > It is the CAs responsibility to make sure the don't issue certificates > to the wrong people, and if they make a mistake they are expected to > quickly add the bad certificate to their published CRL, which is why > you need to check the CRL before trusting the certificate. An > additional check is to make sure the CA that issued the intermediary > certificate that issued the "COMAPNY-NAME" certificate is actually one > of the (few) CAs that "COMPANY-NAME" is going to buy certificates from. > This protects
RE: Certificate pass phrase brute force...
> From: owner-openssl-us...@openssl.org On Behalf Of Gregory Sloop > Sent: Monday, September 15, 2014 22:50 > And, one more question: > How can I tell what format/encryption my pkcs12 files are in? > [I believe for Android platform use, I need p12 certs/keys - so I'm working > on the export/conversion part too.] > I export my cert+key like so: > [openssl pkcs12 -export -aes256 -in somecert.crt -inkey somekey.key -out > somep12.p12] > An "openssl pkcs12 -info -in somecert.p12" gives something like this: > Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 > My take on what that says [which may well be wrong.] > The cert is protected with what appears to be quite a weak chpher, > but we don't care, since it's "public" anyway. Right. > However this looks like the key is encrypted with 3DES, but I "exported" it > from the Cert+Key with "-aes256" - so I'm puzzled why I'd have a 3DES > encrypted p12. You thought you did but you didn't. The doc is a bit subtle, but the -$cipher option is listed under "PARSING". It applies when *reading* a PKCS#12 and extracting the cert(s) and key(s?) to separate files or sections, for (most) other OpenSSL operations, and specifically to encrypting the extracted privatekey section. To specify the PBE algorithm for the key when exporting *to PKCS12*, use -keypbe, as listed on the man page under "EXPORTING". And yes, it isn't very helpful that commandline doesn't warn when you specify a combination of options that doesn't make sense. This is true for most of the commandline functions historically, although a few that have been (re)written recently are better. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate pass phrase brute force...
> From: owner-openssl-us...@openssl.org On Behalf Of Gregory Sloop > Sent: Monday, September 15, 2014 17:14 > I've gone back and re-encrypted the private keys [thanks Dave, again!] > and this is the result from an asn1parse > Is that the new format? [It looks like it, but I'm such a "babe in the > woods," > I'd never know either way with any degree of certainty!] Yes, that's PKCS#8 version 2. Note that the header line in PEM is dash-BEGIN ENCRYPTED PRIVATE KEY, *not* specifying a specific algorithm like RSA PRIVATE KEY, EC PRIVATE KEY, etc. That's how software knows it's PKCS#8 and not legacy. Output from commandline 'pkcs8', either v1 or v2, uses many iterations, unless you use '-noiter'. The noticeable difference is v2 offers a better choice of cipher algorithms. An application calling OpenSSL *library* has more options. > One other related question: I assume more PBKDF key rounds increases > the computational difficulty of checking if some password works against the > file. > [It's a trivial cost in general terms for a single or a few operations, but > becomes a > greater and greater burden with an increasing number of tries. Exactly. The goal is you make it "much too long" for an attacker to try lots and lots of passwords looking for the right one, while a legitimate user on a legitimate system takes only a "little" longer. Exactly what is "much" and "little" is a judgement call; OpenSSL commandline's choice of 2048 (below) is not perfect, but better than 1. > (Yes, I know it doesn't *increase* in difficulty for more tries, it's the > same computational > expense - but increasing a particular key "try time/computational cost" by, > say 0.3s is > probably no big deal unless you need to do a few billion a second.) > Do I have that conceptually right? That reads as inconsistent to me: "it doesn't increase" but "increasing [happens]"? But I think you have the idea. A delay of say 0.3s is tolerable for the legitimate user, but 1billion times 0.3s versus 1billion times 0.01s slows down the attacker. > I read that the number of iterations is 2048. > It appears current versions of the openssl tool now have an option to change > "-iter XXX" where XXX is some number of iterations. [It's in the web/online > manpage, > but not in my Ubuntu 14.04 openssl pkcs8 manpage...] > What version introduced the option to set the number of iterations? > [I'm on 1.0.1f - which I thought should have it.] > I'm trying to do it like this: openssl pkcs8 -topk8 -iter 1 -v2 > aes-256-cbc > [And yes, I also understand the risks of specifying the password on the > command line.] Yes, commandline uses the library default which is 2048, in all releases to date. I think the website may come from the repository, suggesting an -iter option (which would be useful) will be in a future release. Or you can get the source, make a small edit, and build and use that. (iter is already a variable, it's just a variable with two values, 1 or 2048, so it's easy to add other values.) Or you can write a (simple) program rather than use commandline. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
