Re: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems

[Tom Francis]

On May 12, 2017, at 5:00 PM, Michael Wojcik  
wrote:

>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Thomas Francis, Jr.
>> Sent: Friday, May 12, 2017 15:55
>> 
>>> On 5/10/17 3:55 AM, 共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU wrote:
>>> 
>>> I will build OpenSSL on SUSE Linux Enterprise Server for z Systems.
> 
> What version of OpenSSL?
> 
>>> 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.
> 
> Yes, Linux for System z runs on z-architecture CPUs.
> 
>>> 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
>> 
>> 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. :)
> 
> That's certainly the place to start. Whether it will work is another question.
> 
> When we build OpenSSL for z Linux (RHEL and SLES), we use a modified 
> Configure that:
> 
> * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into an 
> archive library that is then linked into a shared object, so we have to force 
> on the shared-object flags in Configure.
> 
> * Replaces -O3 with -O1, preferring robustness (or, if you prefer, toleration 
> for sloppiness and error) and ease of problem determination over performance.
> 
> * Replaces the asm setting[1] with ${no_asm}, for the same reason.
> 
> * For 32-bit, removes /highgprs. According to my notes, highgprs does not 
> work correctly with some glibc versions on zLinux.
> 
> The OP probably doesn't need the first three and may well not need the last. 
> Depending on how clever one gets with building and using OpenSSL, though, 
> config+Configure aren't always sufficient as supplied. That's not a criticism 
> - trying to accommodate every use case is not a good use of the OpenSSL 
> development team's time.
> 
> But unless you're happy with the default build parameters and comfortable 
> with your platform, be prepared to learn how the OpenSSL build works.

I think in general, the same caveat applies for any system. The default build 
settings might not be what you want. But in most cases (including Linux for z), 
they will get you libraries that'll work with the system compiler toolchain if 
you pass only the minimum flags to specify where the headers and libraries can 
be found.

I figure if you need something else you probably already know that, and can 
pass the appropriate flags in CFLAGS, CPPFLAGS, or LDFLAGS. :) Or create a 
custom target. 

TOM

PS Regarding highgprs; I suspect that's actually a problem of mixing 32-bit 
s390x binaries with s390 binaries. There is a difference.  But old bugs and 
miscommunication means that sometimes the s390 system will think it can load an 
s390x binary (and sometimes think it succeeded). :)

> [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit. 
> The linux64-s390x target uses ${s390x_asm} for its asm section, but the 
> linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm 
> for both.
> 
> 
> Michael Wojcik 
> Distinguished Engineer, Micro Focus 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158).

[Tom Francis]

> On Sep 10, 2015, at 8:44 AM, Jayalakshmi bhat  
> wrote:
> 
> Hello all,
> 
> I have a question on FIPS. We have OpenSSL FIPS module integrated with our 
> product. We have an option to enable/disable FIPS at run time.  We are 
> executing the following openSSL API's every time when FIPS status changes.

Typically, this is not allowed; you must restart your application in order to 
switch in or out of FIPS approved mode.  Your customer’s auditor (or your 
auditor) may believe differently, but my former employer had auditors make it 
very clear that an application must never switch into or out of FIPS approved 
mode without restarting the application (and most of the auditors wanted us to 
require the user to reboot their entire system to make the switch; fortunately 
they were willing to allow the application with just an extra note recommending 
the user reboot after modifying the setting).  

> {
>   We have mapped OpenSSL crypto locks to mutex intenally. Hence we delete 
> it and create it every time when FIPS status changes.
>   ERR_free_strings()
>   ERR_remove_state(0);
>   EVP_cleanup();  
>   SSL_library_init()
>   SSLeay_add_all_algorithms()
> }
> 
> Without executing this we are hitting the error, 
> error:0409A09E:lib(4):func(154):reason(158). I wanted to know if our approach 
> is correct?

IIRC you should be able to switch in and out of FIPS appoved mode by simply 
calling FIPS_mode_set() with the appropriate argument.  I know this worked with 
the FIPS 1.2 module, but I never bothered to try it with the 2.0 module (see 
above about allowed uses).  I wouldn’t recommend trying to uninitialize and 
re-initialize OpenSSL, though — while probably safe, it seems like a bad idea.  
If this is a long-running program that can do multiple things at a time, it’s 
definitely a bad idea to allow a toggle like that — someone might’ve started a 
task, then turned on FIPS approved mode — if the task hasn’t done anything with 
OpenSSL yet, it’ll probably be done with FIPS approved mode, but was that the 
user’s intent?  I’d recommend that when a user changes the setting, you store 
the setting and inform the user that the new setting will take affect only 
after restarting the application.

I really doubt you’ll be allowed to switch FIPS approved mode on and off with 
just a simple toggle (even if it works technically).


> Regards
> Jayalakshmi
> ___
> 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] Call for FIPS 140-2 stakeholders

[Tom Francis]

I'm not currently interested in the given platforms, and while I really hope to 
never be interested again, I can't rule it out. It'd be nice to be able to 
follow the discussions, without necessarily contributing. But I also understand 
I if those involved don't want to include those in my position, since I can 
just read your updates, and accept them without knowing all the reasons behind 
it. :) I'm ok either way. 

TOM

-- 
Preserve wildlife -- pickle a squirrel!

 On Jun 22, 2015, at 11:27 AM, Steve Marquess marqu...@openssl.com wrote:
 
 If you don't know or care about FIPS 140-2 then count yourself very
 lucky and move on.
 
 In the same spirit of collaboration that underlies all of the open
 source based OpenSSL FIPS Object Module validations, of which the #1747
 validation is the latest, some of the stakeholders impacted by the
 recent hostage issue[*] are discussing possible responses among
 themselves. I have been told they would like to reach out to other
 interested impacted customers. We know who some of these are, but
 there will be many more users of the #1747 validation on those platforms
 we don't know about.
 
 If you are a such a stakeholder and would like to participate in those
 discussions please let me know (contact info below) and I'll make the
 appropriate introductions.
 
 -Steve M.
 
 [*] see http://openssl.com/fips/aftermath.html
 
 -- 
 Steve Marquess
 OpenSSL Software Foundation, Inc.
 1829 Mount Ephraim Road
 Adamstown, MD  21710
 USA
 +1 877 673 6775 s/b
 +1 301 874 2571 direct
 marqu...@opensslfoundation.com
 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

Re: [openssl-users] Password based key derivation

[Tom Francis]

 On Apr 9, 2015, at 3:13 PM, Deepak dpb795...@gmail.com wrote:
 
 Hi,
 
 Any help on following questions is appreciated.
 
  1)  Can the function PKCS5_PBKDF2_HMAC_SHA1() in 0.9.8zf be used to 
 derive a key for AES-256-CBC encryption from user supplied passphrase?

Yes.

  2) Is PKCS5_PBKDF2_HMAC_SHA1() preferable to EVP_BytesToKey()  and why ? 
 I see PKCS5_PBKDF2_HMAC_SHA1() uses HMACs and is part of standard.

EVP_BytesToKey is pretty old and very simple.  It’s not really appropriate to 
use it for anything new (of course, if you’re trying to remain compatible with 
something that used it in the past, you’d need to keep using it).  You might 
want to consider PKCS5_PBKDF2_HMAC() instead, since some people like to avoid 
SHA-1 these days.  Please note that PKCS5_PBKDF2_HMAC* should be slower than 
EVP_BytesToKey(), and that’s a good thing. :)  See also 
http://openssl-users.openssl.narkive.com/AzXOpacU/openssl-support-for-rfc2898-pbkdf2

  On debugging, could see PKCS5_PBKDF2_HMAC_SHA1() working with 256-bit key 
 but after returning from the function, the data in the stack frame gets 
 corrupted for me and overwrites few other parameters leading to Seg Fault.

That would suggest you’ve misused the function in some way. :)  You might want 
to be sure that you have allocated memory for the out parameter, as it will not 
be allocated for you — that’s the only thing which comes to mind immediately.

TOM

  
 
 Thank you,
 
 Deepak
 
 ___
 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] Is it mandatory to reverse windows signature while doing verification in OpenSSL?

[Tom Francis]

If you mean you’re using CryptSignHash(), and are reversing the bytes in the 
resulting signature, then yes, this is normal.  You’ll need to reverse the 
bytes when verifying the signature with ANY other toolkit/library, including 
CNG. :)  If it’s not too late, you should store the signature with the bytes 
reversed, and then reverse the bytes when you want to verify the signature with 
CryptVerifySignature(), so that nothing else needs to reverse the bytes.  If 
you later switch from CryptoAPI to CNG, then you’ll be able to remove the byte 
reversing code, since CNG uses the same byte order as OpenSSL.

CryptoAPI tends to put all large integer data in least significant byte first 
order (probably because somebody was accustomed to little endian on x86?).  
Every other library I’ve used does the opposite, so I strongly recommend any 
storage be different from what CryptoAPI produces/expects unless your main 
intent is to work only with CryptoAPI.

TOM


 On Apr 1, 2015, at 2:12 AM, Rishabh K Dubey rishabh.du...@igate.com wrote:
 
 Dear,
 
  
 
 We have signed data on Win 7 using Crypto APIs and generated signature. We 
 have observed this such reversing of signature bytes is valid operation or 
 not. Thanks in advance.
 
  
 
 Regards,
 
 Rishabh
 
 
 ~~Disclaimer~~~
 Information contained and transmitted by this e-mail is confidential and 
 proprietary to IGATE and its affiliates and is intended for use only by the 
 recipient. If you are not the intended recipient, you are hereby notified 
 that any dissemination, distribution, copying or use of this e-mail is 
 strictly prohibited and you are requested to delete this e-mail immediately 
 and notify the originator or mailad...@igate.com. IGATE does not enter into 
 any agreement with any party by e-mail. Any views expressed by an individual 
 do not necessarily reflect the view of IGATE. IGATE is not responsible for 
 the consequences of any actions taken on the basis of information provided, 
 through this email. The contents of an attachment to this e-mail may contain 
 software viruses, which could damage your own computer system. While IGATE 
 has taken every reasonable precaution to minimise this risk, we cannot accept 
 liability for any damage which you sustain as a result of software viruses. 
 You should carry out your own virus checks before opening an attachment. To 
 know more about IGATE please visit www.igate.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] FIPS mode uses /dev/urandom ?

[Tom Francis]

 On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero aro...@alienvault.com 
 wrote:
 
 Dear all, I'm doing an strace to the FIPS validated version of
 openssl, and I'm seeing that is uses /dev/urandom. I thought that the
 FIPS validated module always use /dev/random, isn't this the case, or
 am I doing something wrong?.
 
 If it uses /dev/urandom, is it possible/advisable to change it to
 /dev/random (how?), and still the module being FIPS validated?

It would depend on what code is reading from /dev/urandom.  If it’s the FIPS 
Object Module that’s doing the reading, then no, absolutely not.  If it’s the 
FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it.  
But I’m curious as to why you would want to do this.  Most systems with 
/dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the 
preferred source for “random data”, including when seeding a PRNG (which is how 
it’s used by OpenSSL).  And because /dev/random can block, you might have 
ridiculously poor performance (and worse, it’ll be unpredictably poor 
performance, i.e. sometimes it’ll work great, and other times it’ll be 
horrible, and you never which you’ll get).  This page, 
http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a 
high-level, It’s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD 
(OpenBSD is more complex).  I’m not about other UNIX-like systems, as I stopped 
using those before any of them ever provided such devices. :)

TOM

 Thanks for your help in advance and best regards,
 Alberto.
 ___
 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] Testing FIPS mode using 0 randomness

[Tom Francis]

 On Mar 2, 2015, at 12:18 PM, jonetsu jone...@teksavvy.com wrote:
 
 Hello,
 
   I tried a simple test to see if FIPS mode would fail, using the example 
 given in the FIPS user guide 2.0.  The test consisted of replacing the 
 /dev/random and /dev/urandom with /dev/zero.  I would have expected that no 
 source of randomness would make the tests ran at the call of FIPS_mode_set(1) 
 fail.
 
 ex.:
 
 cd dev
 rm random
 mknod -m 666 /dev/random c 1 5
 
 Verify presence of zeroes all over:
 cat /dev/random | xxd
 
 ./fips_hmac fips_hmac.o
 
 If added a ret value to catch the return code from FIPS_mode_set(1).  Random 
 or no random, it always returns 1.  
 
 Shouldn't randomness be an important part of the power-up tests ?  I 
 understand there are continuous RNG tests within OpenSSL FIPS mode, although 
 'later on' (eg. continuous). Wouldn't these tests be part of the power-up 
 sequence as called by FIPS_mode_set(1) also ?

No.  The self-tests verify the output of the algorithms matches for given 
input.  This means when the PRNG is tested, it’s seeded with known values, and 
the output is checked against the correct output for the way it was seeded.  
Inputs from /dev/random, /dev/urandom, or any other “random” source are not 
used.

Remember, the goal of FIPS 140 is NOT “good security”, it’s “verifying that 
known cryptographic algorithms are used”.  If the input and output are not 
predictably the same, then how can you verify the algorithm used is the 
algorithm that’s supposed to be used?  And attempting to account in the tests 
for every possible input (what you’d have to do if you didn’t only test a small 
number of known inputs) would be impractical, at best. :)

TOM

 Thanks.
 
 
 ___
 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] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link with pthread error

[Tom Francis]

 On Mar 2, 2015, at 4:18 AM, Mrunal Nerpawar p.mru...@gmail.com wrote:
 
 Thanks Tom for the reply.
 
 I know I am replying really late, but the option you mentioned is tried but 
 is not working either. :(
 
 Anything else i can try?

Since I no longer have access to that compiler, and I don’t generally bother 
with FIPS 140 anymore, I can’t be sure, but I suspect the problem is described 
here:

http://h21007.www2.hp.com/portal/download/files/prot/files/linker/onlinehelp/compileandlink.htm
 (see “Linker Thread-safe features”).

Originally, I was thinking this was an actual link error, but now that I think 
about it, it’s probably coming from when fips_premain_dso is run to determine 
the signature to be embedded.  And if that’s the case, you’re pretty much out 
of luck — there’s no way to modify fips_premain_dso to avoid the shl_load() 
call (not and still be following the security policy), and there’s no way to 
make shl_load() succeed. shl_load() simply doesn’t work with TLS.  If you could 
somehow change your use of OpenSSL and the FIPS Object Module such that OpenSSL 
is linked statically into an executable (that is, a complete executable, not a 
shared library) then you could probably make it work. :(

You can verify if that’s the case by adding more output to your fipsld script; 
I suspect you’ll see the failure from the line:

SIG=`”${PREMAIN_DSO}” “${TARGET}”`

There should be code in fipsld to error out if that failed, but perhaps that 
was disabled?  Anyway, if the error is not from invoking fips_premain_dso, then 
something else is wrong, and I’d suggest opening a support case with HP.

TOM

 -Mrunal
 
 On Wed, Feb 25, 2015 at 8:31 AM, Tom Francis thomas.francis...@pobox.com 
 wrote:
 Have you tried changing FIPSLD_CC and FIPSLD_LINK to include the necessary 
 options (e.g. -mt)?  Note: it might be simpler to modify fipsld instead, 
 depending on how easy/hard it is to maintain spaces properly when settings 
 FIPSLD_CC and FIPSLD_LINK.  Since the fipsld script is just a convenience 
 script to help you meet the requirements of the security policy, you’re free 
 to modify it.  Just don’t modify it such that the security policy is no 
 longer followed.  Generally speaking, adding more options to the compile and 
 link steps will be safe.
 
 TOM
 
  On Feb 23, 2015, at 4:36 AM, Mrunal Nerpawar p.mru...@gmail.com wrote:
 
  Details
  ==
  Fips 2.0.5 configured with no-asm and threads.
  Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos 
  omitted)
  compiler -  using aCC 6.25 on HPUX-IA64 11.23.
 
  bash-2.05$ aCC --version
  aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
  bash-2.05$
 
  product linking with fipsld fails with error ...
  =
  :DLFCN_LOAD:could not load the shared 
  library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it 
  contains thread specific data.
 
  Options tried
  ==
  * Compiling Cxx sources with -mt.
  * Linking with -lpthread,
  * setting LD_PRELOAD.
  None worked effectively. with LD_PRELOAD option, ended up getting error - 
  undefined symbol Ztil, etc.
 
  complete error is as follows.
  =
 
  Building shared library 
  objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
  FIPSLD_CC=aCC FIPSLD_LINK=aCC 
  /unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld
+Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o 
  objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0 
  objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o 
  objs/HP-UX-B.11.23-ia64-64/LSSpawner.o 
  objs/HP-UX-B.11.23-ia64-64/LSFilter.o 
  objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o 
  objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o 
  objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o 
  objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o 
  objs/HP-UX-B.11.23-ia64-64/GroupUtil.o 
  objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o 
  objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o 
  objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o 
  objs/HP-UX-B.11.23-ia64-64/MachineUtil.o 
  objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o 
  objs/HP-UX-B.11.23-ia64-64/NSSwitch.o 
  objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o 
  objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o 
  objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o 
  objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o 
  objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o 
  objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o 
  objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o 
  objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o 
  objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o 
  objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o 
  objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o 
  objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o 
  objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o 
  objs/HP-UX-B.11.23-ia64-64

Re: [openssl-users] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link with pthread error

[Tom Francis]

Have you tried changing FIPSLD_CC and FIPSLD_LINK to include the necessary 
options (e.g. -mt)?  Note: it might be simpler to modify fipsld instead, 
depending on how easy/hard it is to maintain spaces properly when settings 
FIPSLD_CC and FIPSLD_LINK.  Since the fipsld script is just a convenience 
script to help you meet the requirements of the security policy, you’re free to 
modify it.  Just don’t modify it such that the security policy is no longer 
followed.  Generally speaking, adding more options to the compile and link 
steps will be safe.

TOM

 On Feb 23, 2015, at 4:36 AM, Mrunal Nerpawar p.mru...@gmail.com wrote:
 
 Details
 ==
 Fips 2.0.5 configured with no-asm and threads.
 Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos 
 omitted) 
 compiler -  using aCC 6.25 on HPUX-IA64 11.23.
 
 bash-2.05$ aCC --version
 aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
 bash-2.05$
 
 product linking with fipsld fails with error ...
 =
 :DLFCN_LOAD:could not load the shared 
 library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
   Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it 
 contains thread specific data.
 
 Options tried
 ==
 * Compiling Cxx sources with -mt.
 * Linking with -lpthread,
 * setting LD_PRELOAD.
 None worked effectively. with LD_PRELOAD option, ended up getting error - 
 undefined symbol Ztil, etc.
 
 complete error is as follows.
 =
 
 Building shared library objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
 FIPSLD_CC=aCC FIPSLD_LINK=aCC 
 /unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld
   +Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o 
 objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0 
 objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o 
 objs/HP-UX-B.11.23-ia64-64/LSSpawner.o objs/HP-UX-B.11.23-ia64-64/LSFilter.o 
 objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o 
 objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o 
 objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o 
 objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o 
 objs/HP-UX-B.11.23-ia64-64/GroupUtil.o 
 objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o 
 objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o 
 objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o 
 objs/HP-UX-B.11.23-ia64-64/MachineUtil.o 
 objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o 
 objs/HP-UX-B.11.23-ia64-64/NSSwitch.o objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o 
 objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o 
 objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o 
 objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o 
 objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o 
 objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o 
 objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o 
 objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o 
 objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o 
 objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o 
 objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o 
 objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o 
 objs/HP-UX-B.11.23-ia64-64/FieldUtils.o 
 objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o 
 objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o 
 objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o 
 objs/HP-UX-B.11.23-ia64-64/Timestamp.o objs/HP-UX-B.11.23-ia64-64/Timespan.o 
 objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o 
 objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o 
 objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o 
 objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o 
 objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o 
 objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o 
 objs/HP-UX-B.11.23-ia64-64/RFUtilities.o 
 objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o 
 objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o 
 objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o 
 objs/HP-UX-B.11.23-ia64-64/Debugger.o objs/HP-UX-B.11.23-ia64-64/Exception.o 
 objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o 
 objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o 
 objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o 
 objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o 
 objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o 
 objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o 
 objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o 
 objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o 
 objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o 
 objs/HP-UX-B.11.23-ia64-64/DigestEngine.o 
 objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o 
 objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o 
 objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o 
 objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o 
 

Re: [openssl-users] FIPS methods and symlinks

[Tom Francis]

 On Feb 24, 2015, at 9:42 PM, jone...@teksavvy.com wrote:
 
 On Tue, 24 Feb 2015 16:16:17 +
 Dr. Stephen Henson st...@openssl.org wrote:
 
 On Tue, Feb 24, 2015, jonetsu wrote:
 
 Hello,
 
   To grasp how FIPS methods are called, and following one method
 as an example, HMAC_Update() in hmac.c, we can see that if FIPS
 mode is active then FIPS_hmac_update() will be called.  This is
 fine although searching the sources for the physical definiton of
 FIPS_hmac_update() does not yield any results.  How does the
 symbolic links function, what ends up being executed in this case
 and through which path ?
 
 Function names get changed through fips/fipssyms.h in the FIPS module
 source.
 
 Yes, for instance there is:
 
 #define HMAC_Update FIPS_hmac_update
 
 My question is about not having found FIPS_hmac_update.  If it is
 called, then where is it ?  May sound like a simple question, although
 grep did not return any actual method.  

You’ll find it in the FIPS Object Module.  But in the source for the FIPS 
Object Module, it’s called HMAC_Update.  You just need to read the table 
backwards.  If you want to understand why, think about it a moment.  The module 
is mostly just a specific, tested, version of OpenSSL’s libcrypto (with extra 
fluff added, and some stuff removed*).  It was pretty simple** to just keep the 
source identical (with appropriate #ifdef to control adding in the fluff and 
removing other things), and then rename all the symbols in the result to avoid 
duplicate symbols.  It may make it a little harder to follow after the fact, 
but it’s really not that hard — HMAC_Update() in your FIPS-capable libcrypto 
will invoke the renamed HMAC_Update() in the FIPS Object Module when operating 
in FIPS mode.

Steve Marquess: Is the document (which IIRC, you published back before the 
first validation) on how/why the FIPS Object Module was coded still available 
somewhere?  If so, that’d probably be a good starting point for people who post 
questions like this.  It’s certainly not something that’s easy to figure out if 
one doesn’t already have an idea of what’s going on. :)

TOM

* That’s probably not the best way to put it, it’s certainly not precise. :)
** Says a guy who in no way contributed to that effort. :)

 ___
 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] The evolution of the 'master' branch

[Tom Francis]

I think Jakob’s real concern (as expressed to me off-list a month or so ago) is 
that OpenSSL’s libcrypto will become entirely hidden.  I found several of his 
comments confusing until he mentioned that.  So, I think the fair question to 
be asking is:

Is there any plan to make libcrypto go completely opaque, such that _only_ the 
APIs exposed in libssl will be available?

Thanks!

TOM

 On Feb 6, 2015, at 11:03 AM, Jakob Bohm jb-open...@wisemo.com wrote:
 
 On 05/02/2015 00:42, Salz, Rich wrote:
 Not much on that page so far, not even a kill list of
 intended victims except an admission that EAY's popular DES
 library can no longer be accessed via the copy in OpenSSL.
 
 Yup.  Pretty empty.  Over the coming year there will be more.
 
 I fear that this is an indication that you will be killing
 off all the other non-EVP entrypoints in libcrypto
 
 Yes there is a good chance of that happening.
 
 , making
 it much harder to use the library with experimental or
 non-standard algorithms and methods.
 
 Well, not really much harder.  I think that what DOES get harder is binary 
 distributions of such things, as opposed to custom OpenSSL builds that have 
 these new features.  Don't forget, *you have the source*  Hack away.  Do 
 what you want.  And having a standard API that any of your consumers use 
 will benefit your consumers greatly.  And by making things like the EVP 
 structure hidden from your consumers, then you can add a new experimental 
 crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES 
 NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For 
 your users, it is much easier.  Imagine being able to put an OID in a config 
 file and applications can almost transparently use any crypto available 
 without change.  (Emphasis on ALMOST :)  To us, this is clearly the right 
 trade-off to make.
 
 You seem to misunderstand the scenario:
 
 My scenario is:
 
 1. Load an unchanged shared libcrypto.so.1.1 provided by an
   OS distribution.
 
 2. Implement / use / experiment with non-standard methods
   (such as new modes of operation or new zero-knowledge
   proofs) by calling the functions that are exported by
   libcrypto out of the box.  The higher level libssl is
   not used for anything.
 
 Your scenario is:
 
 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non-
   standard methods (such as new modes of operation or new
   signature forms).
 
 2. Inject this new functionality into existing applications
   that use OpenSSL in generic ways, such as wget and WebKit
   browsers.
 
 My scenario got great advantages from the large number of
 fundamental interfaces exported from libcrypto.so.1.0 and
 will automatically benefit when a new patch release of
 OpenSSL is installed on the system (e.g. to fix a timing
 attack on one of the algorithm implementations).  Having
 to create a custom libnotquitecrypto.so.1.1 would not do
 this, and distributing such a library as source patches
 became much harder when you reformatted the source.
 
 Looking at the reverse dependencies in Debian, the
 following projects probably use low level libcrypto
 interfaces to do interesting things: afflib, asterisk,
 bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,
 faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,
 hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,
 ldnsutils, apache mod-auth-cas, apache mod-auth-openid,
 perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,
 StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,
 openssh, rdd, rdesktop, rsyncrypto, samdump, tor,
 tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.
 *This is only a rough list based on features claimed by
 OpenSSL-depending packages*
 
  
 Should everyone not doing just TLS1.2 move to a different library now, such 
 as crypto++ ?
 
 Use whatever works best for you, and your consumers/customers.
 
 Not everyone will agree with this direction. Some people will be 
 inconvenienced and maybe even completely drop using OpenSSL. We discussed 
 this pretty thoroughly, and while we respect that some may disagree, please 
 give us credit for not doing this arbitrarily, or on a whim.  
 
 I believe you have made the mistake of discussing only amongst
 yourselves, thus gradually convincing each other of the
 righteousness of a flawed decision.
 
  
 Enjoy
 
 Jakob
 -- 
 Jakob Bohm, CIO, Partner, WiseMo A/S.  
 http://www.wisemo.com
 
 Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 WiseMo - Remote Service Management for PCs, Phones and Embedded 
 
 ___
 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] Using FIPS mode and modifying apps

[Tom Francis]

 On Jan 28, 2015, at 8:47 AM, Dr. Stephen Henson st...@openssl.org wrote:
 
 On Wed, Jan 28, 2015, jone...@teksavvy.com wrote:
 
 On Mon, 26 Jan 2015 22:35:12 -0500
 Tom Francis thomas.francis...@pobox.com wrote:
 
 Thanks for the detailed comments.  I understand the concerns, although
 there's one thing I do not see clearly, that is:
 
 2) Applications that don???t know they???re operating in FIPS
 mode may attempt to use algorithms that are disallowed in FIPS mode,
 but using an API that will actually succeed.  
 
 How could this happen ?  Do you have a practical use case ?  Wouldn't
 OpenSSL in FIPS mode prevent the use of such algorithm in the first
 place ?
 
 
 OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but 
 applications don't always cleanly handle it.
 
 If the application uses TLS then it should be OK as non-FIPS ciphersuites
 are automatically blocked. A possible gotcha is use of private keys encrypted
 using the old MD5 PBE algorithm.
 
 If the application uses algorithms directly via for example 
 EVP_DigestInit_ex()
 then things are different. A non-FIPS application might never see an error
 from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the
 return value). This will cause a hard failure later on.
 
 Even if an application does check return values it might regard an error
 return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory
 allocation failure): it is unlikely to retry with a different algorithm.
 
 The correct thing to do is never attempt to use the non-FIPS algorithm in
 the first place. What that measn in practice is that while some applications
 will just work when FIPS mode is enabled, others need to be modified to
 correctly handle FIPS.

Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where 
OpenSSL would prevent disallowed algorithms from being used, but only if you 
used the EVP interfaces. You could, for example, invoke MD5 directly.  Did that 
change with 2.x?  (it’s not something I paid much attention to, as I always 
used EVP, anyway).  It’s also my understanding that the private APIs could 
still be used to bypass the FIPS mode algorithm checks, and that some 
applications may be using those.

TOM


 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 ___
 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] Using FIPS mode and modifying apps

[Tom Francis]

 On Jan 28, 2015, at 8:47 AM, Dr. Stephen Henson st...@openssl.org wrote:
 
 On Wed, Jan 28, 2015, jone...@teksavvy.com wrote:
 
 On Mon, 26 Jan 2015 22:35:12 -0500
 Tom Francis thomas.francis...@pobox.com wrote:
 
 Thanks for the detailed comments.  I understand the concerns, although
 there's one thing I do not see clearly, that is:
 
 2) Applications that don???t know they???re operating in FIPS
 mode may attempt to use algorithms that are disallowed in FIPS mode,
 but using an API that will actually succeed.  
 
 How could this happen ?  Do you have a practical use case ?  Wouldn't
 OpenSSL in FIPS mode prevent the use of such algorithm in the first
 place ?
 
 
 OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but 
 applications don't always cleanly handle it.
 
 If the application uses TLS then it should be OK as non-FIPS ciphersuites
 are automatically blocked. A possible gotcha is use of private keys encrypted
 using the old MD5 PBE algorithm.
 
 If the application uses algorithms directly via for example 
 EVP_DigestInit_ex()
 then things are different. A non-FIPS application might never see an error
 from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the
 return value). This will cause a hard failure later on.
 
 Even if an application does check return values it might regard an error
 return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory
 allocation failure): it is unlikely to retry with a different algorithm.
 
 The correct thing to do is never attempt to use the non-FIPS algorithm in
 the first place. What that measn in practice is that while some applications
 will just work when FIPS mode is enabled, others need to be modified to
 correctly handle FIPS.

Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where 
OpenSSL would prevent disallowed algorithms from being used, but only if you 
used the EVP interfaces. You could, for example, invoke MD5 directly.  Did that 
change with 2.x?  (it’s not something I paid much attention to, as I always 
used EVP, anyway).  It’s also my understanding that the private APIs could 
still be used to bypass the FIPS mode algorithm checks, and that some 
applications may be using those.

TOM


 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 ___
 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] Using FIPS mode and modifying apps

[Tom Francis]

 On Jan 26, 2015, at 6:21 PM, jone...@teksavvy.com wrote:
 
 On Fri, 16 Jan 2015 10:16:48 -0500
 Steve Marquess marqu...@openssl.com wrote:
 
 On 01/15/2015 05:52 AM, Marcus Meissner wrote:
 
 On Linux usually triggered by /proc/sys/crypto/fips_enabled
 containing 1 or the environment variable
 OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and
 Redhat, which do not use the container blob).
 
 That is (presumably) true for the proprietary RH and SUSE distros,
 not so for the open source based OpenSSL FIPS Object Module or other
 Linux distros.
 
 I'm afraid it does not come across clear to me.  So, maybe the
 following pondering is relevant - or not.  Basically, I'm looking at
 how to integrate a FIPS-enabled OpenSSL that will be used by some
 common Open Sources applications, as well as a 3rd party application
 (with source code provided).

This is a bad idea.  It can generally be done, and it’s probably not even too 
hard (for some uses, anyway).  But it’s a bad idea.  Here’s why:

1) Applications that don’t know they’re operating in FIPS mode may attempt to 
use algorithms that are disallowed in FIPS mode.  Because the application 
wasn’t designed for this situation, if the algorithm is attempted through the 
proper APIs, use of the algorithm will fail, and the application’s error report 
will be incorrect (assuming it even handles the error coming from OpenSSL, and 
doesn’t fail much later!).
2) Applications that don’t know they’re operating in FIPS mode may attempt to 
use algorithms that are disallowed in FIPS mode, but using an API that will 
actually succeed.  This will cause issues for the USER, since the user believes 
the application is operating properly in FIPS mode, when it just did something 
that’s disallowed!
3) Applications that don’t know they’re operating in FIPS mode may attempt to 
use SHA-1 in operations that are disallowed in FIPS mode.  OpenSSL will allow 
most uses of SHA-1 in FIPS mode, relying on the application to only use it 
appropriately.  Again, this can cause problems for the user who thinks the 
application is operating in FIPS mode, but the application has done things that 
are disallowed!
4) If POST fails or some other problem is detected, where FIPS mode fails to be 
enabled, an application that doesn’t know anything about FIPS mode will fail in 
a manner unexpected by the application.  Even if you’ve found a way to notify 
the user (ha! how you gonna do that not knowing if the application is graphical 
or not, has access to stderr, syslog, or something else entirely?), the 
application’s failure may not release resources appropriately, or may cause 
other problems, especially for the end user who keeps trying it over and over 
again. :)

Someone who controls all the applications on a system, however, that one could 
deal with all of those issues and more.  It’d be expensive, and one would 
probably be unwilling to give that work away whenever one doesn’t have to. :)

I’ll let Steve answer the stuff I snipped. :)
snip

TOM
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS JCE cryptographic modules usage with Openssl-1.0.1j and openssl-fips-2.0.7

[Tom Francis]

 On Jan 21, 2015, at 8:09 AM, Philip Bellino pbell...@mrv.com wrote:
 
 Hello,
 
 I apologize if this is not the correct forum for my questions, so here goes.
 
  
 
 1.   Are the RSA JSafeJCE and the IBM’ IBMJESFIPS cryptographic modules 
 being used widely against Openssl in FIPS mode?

In what way do you mean “against”?  As in two (or more) programs communicating 
with one another, at least one of which uses OpenSSL and at least one of which 
uses one of the others?  Or as in those modules being used in preference to 
OpenSSL?  If the former, I’m not aware of anything in particular.  However, it 
should be noted that the FIPS validations would mean the actual algorithm are 
compatible, so there’s no reason they couldn’t be used in such ways, assuming 
appropriate care is taken to use equivalent parameters, keys, etc.  If the 
latter, I’m not sure if there’s any way to measure that, and any measurement is 
probably meaningless, taken in total — it’d be more meaningful to make such 
determinations with respect to a particular type of application or a more 
specific customer space (although the latter is already pretty specific, since 
requiring FIPS 140 isn’t exactly a general customer thing).

 2.   If so, have these modules kept pace with the latest Openssl FIPS 
 implementation.

I don’t quite follow.  Those products are entirely separate from OpenSSL (and 
each other), and none of them affect any of the others.  Indeed, because of the 
way validation testing is performed and interpreted, one implementation may 
have more onerous changes enforced than another.  If you’re wondering about new 
interpretations that have caused changes in OpenSSL, and if those 
interpretations have also affected those implementations, you’d need to ask RSA 
and IBM.  I doubt they’ll tell you anything other than the appropriate 
certificate numbers for their products, and let you look up the dates they were 
awarded, though.  :)

TOM


  
 
 Thank you.
 
  
 
  
 
  
 
  
 
 Phil Bellino
 
 Principal Software Engineer | MRV Communications Inc.
 
 300 Apollo Drive |  Chelmsford, MA 01824
 
 Phone: 978-674-6870  |   Fax: 978-674-6799
 
 www.mrv.com
 
 
  
 
 image001.png
  
 
  
 
 
  
 The contents of this message, together with any attachments, are intended 
 only for the use of the person(s) to whom they are addressed and may contain 
 confidential and/or privileged information. If you are not the intended 
 recipient, immediately advise the sender, delete this message and any 
 attachments and note that any distribution, or copying of this message, or 
 any attachment, is prohibited.
 
 ___
 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 JCE cryptographic modules usage with Openssl-1.0.1j and openssl-fips-2.0.7

[Tom Francis]

 On Jan 21, 2015, at 8:09 AM, Philip Bellino pbell...@mrv.com wrote:
 
 Hello,
 
 I apologize if this is not the correct forum for my questions, so here goes.
 
  
 
 1.   Are the RSA JSafeJCE and the IBM’ IBMJESFIPS cryptographic modules 
 being used widely against Openssl in FIPS mode?

In what way do you mean “against”?  As in two (or more) programs communicating 
with one another, at least one of which uses OpenSSL and at least one of which 
uses one of the others?  Or as in those modules being used in preference to 
OpenSSL?  If the former, I’m not aware of anything in particular.  However, it 
should be noted that the FIPS validations would mean the actual algorithm are 
compatible, so there’s no reason they couldn’t be used in such ways, assuming 
appropriate care is taken to use equivalent parameters, keys, etc.  If the 
latter, I’m not sure if there’s any way to measure that, and any measurement is 
probably meaningless, taken in total — it’d be more meaningful to make such 
determinations with respect to a particular type of application or a more 
specific customer space (although the latter is already pretty specific, since 
requiring FIPS 140 isn’t exactly a general customer thing).

 2.   If so, have these modules kept pace with the latest Openssl FIPS 
 implementation.

I don’t quite follow.  Those products are entirely separate from OpenSSL (and 
each other), and none of them affect any of the others.  Indeed, because of the 
way validation testing is performed and interpreted, one implementation may 
have more onerous changes enforced than another.  If you’re wondering about new 
interpretations that have caused changes in OpenSSL, and if those 
interpretations have also affected those implementations, you’d need to ask RSA 
and IBM.  I doubt they’ll tell you anything other than the appropriate 
certificate numbers for their products, and let you look up the dates they were 
awarded, though.  :)

TOM


  
 
 Thank you.
 
  
 
  
 
  
 
  
 
 Phil Bellino
 
 Principal Software Engineer | MRV Communications Inc.
 
 300 Apollo Drive |  Chelmsford, MA 01824
 
 Phone: 978-674-6870  |   Fax: 978-674-6799
 
 www.mrv.com
 
 
  
 
 image001.png
  
 
  
 
 
  
 The contents of this message, together with any attachments, are intended 
 only for the use of the person(s) to whom they are addressed and may contain 
 confidential and/or privileged information. If you are not the intended 
 recipient, immediately advise the sender, delete this message and any 
 attachments and note that any distribution, or copying of this message, or 
 any attachment, is prohibited.
 
 ___
 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] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1)

[Tom Francis]

 On Jan 20, 2015, at 3:00 PM, Nou Dadoun ndad...@teradici.com wrote:
 
 Thanks for the clarification, a couple of short questions - 
 
 We already have a shim to index into the function table that gets loaded 
 after run-time selecting from the 0.9.8 FIPS vs non-FIPS dll to use.  I 
 imagined that we might have to thicken the shim  to accommodate selection 
 between 0.9.8-FIPS and 1.0.1 non-FIPS (unorthodox I know but a potential 
 short term step forward).   Couldn't they be made interchangeable with 
 appropriate changes to the shim or is there some more fundamental 
 incompatibility?

Probably, but I’d strongly recommend against what you’re doing.  You should 
instead link only ONE library, and call FIPS_mode_set() when you want to use 
FIPS Approved mode, and do not call that when you do not want to use FIPS 
Approved mode.  I’m not sure why you would do so much excess work for something 
that was provided for already with a single function call.  If it’s because you 
want to switch between use of FIPS or not within the same process, then you’ve 
misunderstood what FIPS 140 validation is for, and you’re doing it wrong.  Even 
with the strange (and loose) interpretations of FIPS 140 the government 
auditors approve. :)

 I looked at the  link you provided for OpenSSL FIPS Object Module v2.0, 
 validation certificate #1747 (thanks very much for that); another interesting 
 consideration but I was surprised to notice that omitted from the list of 
 supported algorithms was any mention of SHA, is no variant of SHA supported 
 at all?

That’s the reference to SHS — Secure Hashing Standard.  See 
http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm for more info if 
you’d like. :)

 Thanks again … N

TOM

 -Original Message-
 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
 Steve Marquess
 Sent: January-20-15 8:17 AM
 To: openssl-users@openssl.org
 Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS 
 (1.0.1)
 
 On 01/19/2015 12:42 PM, Nou Dadoun wrote:
 The scenario that we're contemplating is having FIPS based on 0.9.8??
 coexist with 1.0.1?? so the remapping at runtime would have to account 
 for api differences within the two.  This was really the upshot of my 
 question.
 
 The 1.2 FIPS module (FIPS based on 0.9.8) is not compatible with OpenSSL 
 1.0.1. You need the 2.0 FIPS module for that.
 
 But I think I'm still a little confused about the FIPS-certification 
 of OpenSSL 1.0.1??,...
 
 It's validation, not certification.
 
 I remember reading that some of the FIPS power on self-test 
 requirements precluded a general FIPS certification, is that the case? 
 ...
 
 I think you're conflating several issues here. What you're probably referring 
 to is the fact that some new requirements for *new* FIPS 140-2 validations 
 (IG 9.10 among them) mean that the source code for the 2.0 FIPS module can no 
 longer be used as-is for new validations. Those new requirements have 
 impacted those vendors desiring to pursue such private label or copycat 
 validations, but has not affected the original 2.0 FIPS module that was used 
 as the model for such private label validations.
 
 What is the status of FIPS OpenSSL certification?
 (Is this written up anywhere?)
 
 The OpenSSL FIPS Object Module v2.0, validation certificate #1747, remains 
 available for use with (to date) 102 formally tested platforms:
 
  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
 
 -Steve M.
 
 --
 Steve Marquess
 OpenSSL Software Foundation, Inc.
 1829 Mount Ephraim Road
 Adamstown, MD  21710
 USA
 +1 877 673 6775 s/b
 +1 301 874 2571 direct
 marqu...@opensslfoundation.com
 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
 

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EVP_DigestVerifyFinal return code?

[Tom Francis]

 On Jan 15, 2015, at 3:41 AM, Jeffrey Walton noloa...@gmail.com wrote:
 
 According to the man pages on EVP_DigestVerifyFinal
 (https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html):
 
EVP_DigestVerifyInit() and EVP_DigestVerifyUpdate() return 1 for
success and 0 or a negative value for failure...
 
 I have an unexplained failure in EVP_DigestVerifyInit (i.e., its not
 returning 1).
 
 Looking at apps/dgst.c, around line 580:
 
if(sigin)
{
EVP_MD_CTX *ctx;
BIO_get_md_ctx(bp, ctx);
i = EVP_DigestVerifyFinal(ctx, sigin, (unsigned int)siglen);
if(i  0)
BIO_printf(out, Verified OK\n);
else if(i == 0)
{
BIO_printf(out, Verification Failure\n);
return 1;
}
else
{
BIO_printf(bio_err, Error Verifying Data\n);
ERR_print_errors(bio_err);
return 1;
}
return 0;
}
 
 So does EVP_DigestVerifyInit return 1 on success, or does it return
 something else? If its 1, then digst.c is wrong. If its something else
 (like 0), then the docs are wrong.

IIRC (from when I looked at it before replying on a different list to you), it 
only returns 1 on success and 0 on failure.  I suspect the author of the apps 
code modified it to check for  0, because a while back, it was determined that 
a few functions that used to only return 1 for success and 0 for failure were 
updated to return other  0 values for success and some  0 values for failure, 
which caused some of openssl apps to .  This kind of check future-proofs the 
app code from such a future change.

TOM

 Is anyone familiar with this function who can comment?
 ___
 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: EVP_verify APIs

[Tom Francis]

 On Oct 27, 2014, at 4:33 AM, Gayathri Manoj gayathri.an...@gmail.com wrote:
 
 Hi All,
 
 How can I replace RSA_public_decrypt() with EVP_Verify*().
 
 I  wanted to replace the below api with EVP_verify*()
 
 RSA_public_decrypt(Len, SgnData, dBuffer,  rsa_pub_key, RSA_PKCS1_PADDING);
 

You’d need to share more of the code around the call to RSA_public_decrypt().  
RSA_public_decrypt() only does some of the work done by EVP_Verify*.  
EVP_Verify* are intended to:

1) Hash user data using the hash type passed to EVP_VerifyInit(), SHA1 in your 
example below, using EVP_VerifyUpdate();
2) Decrypt the encrypted data (SgnData in your example below) in 
EVP_VerifyFinal(); and
3) Verify the hash type specified in EVP_VerifyInit() matches the one in the 
decrypted data from step 2, and verify the hash value from step 1 matches the 
hash value in the decrypted data from step 2.

Your code below probably fails because you didn’t pass the correct data to 
EVP_Update(), SgnData isn’t in a valid signature format, OR you use the wrong 
keys somewhere. :)

Oh, and the signature algorithm for the certificate is meaningless unless 
you’re trying to verify the certificate’s signature —- and if you want to do 
that, I strongly recommend using X509_verify_cert() for verifying the 
certificate’s signature, if at all possible, and X509_check_issued() if you 
can't.

TOM

 I have tried with 
 
 EVP_MD_CTX md_ctx;
 unsigned char *decryptBuffer = NULL;
 EVP_PKEY *pubKey = NULL;
 PubKey = X509_get_pubkey(X509cert);
 decryptBuf = (uchar *) malloc(EVP_MD_size(EVP_sha1()));
 
 EVP_VerifyInit(md_ctx, EVP_sha1());
 EVP_VerifyUpdate (md_ctx, dBuffer, strlen(dBuffer)-1);
 errorCode = EVP_VerifyFinal(md_ctx, SgnData, Len, PubKey);
 
 Getting errorCode as 0. ERR[bad signature]
 
 certificate's Signature Algorithm is SHA256withRSA
 
 Please let me know how can I solve this issue.
 
 Thanks,
 Gayathri

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Symmetrical encryption in FIPS mode?

[Tom Francis]

Your assumption is incorrect.  Note that when you use the FIPS module, that you 
should not attempt to use the FIPS module directly — instead, you build a 
separate version of OpenSSL that uses the FIPS module (after building the FIPS 
module).  You then link the new libcrypto (and libssl if you need it), and 
invoke the usual OpenSSL functions.  If your application calls FIPS_mode_set() 
first, then the FIPS module will be used for all crypto routines, while regular 
OpenSSL stuff is used for non-crypto functionality.  If you don’t call 
FIPS_mode_set() first, then cryptographic routines come from the regular 
OpenSSL library*, and your application cannot be considered as using any kind 
of FIPS 140 module.  

See the FIPS User’s guide for more info, because FIPS 140 compliance means that 
some cryptographic algorithms are disabled when in “FIPS mode”.  IIRC, there’s 
also a full list of algorithms that are available in FIPS mode in the User’s 
guide, and if not, the Security Policy should detail that information.

TOM

* IIRC, there’s a bug when using the 1.x FIPS modules, where all encryption 
still routes through the FIPS module, even when not in FIPS mode, unless the 
algorithm is unavailable in the FIPS module.  I don’t recall if that problem 
was fixed for use with the current FIPS module.

On Oct 2, 2014, at 12:49 PM, Graham Leggett minf...@sharp.fm wrote:

 Hi all,
 
 Looking at the headers in the FIPS module of openssl, I see none of the 
 EVP_Encrypt* functions are available. Am I assuming correctly that no 
 symmetrical encryption is possible at all in FIPS mode?
 
 Regards,
 Graham
 —
 
 __
 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: openssl-0.9.8za fips compliance

[Tom Francis]

Use of -no-ec when building the FIPS capable openssl doesn’t affect the FIPS 
module at all, and therefore doesn’t affect any statements you can make 
regarding FIPS 140 compliance.  The -no-ec option will prevent elliptic curve 
cryptography from being used in OpenSSL when NOT using the FIPS module, and 
does not affect OpenSSL when using the FIPS module.  The FIPS module is used 
only when FIPS mode is enabled by calling FIPS_mode_set().

I’m somewhat concerned, though, by your questions in a previous thread, so I’d 
like to clarify: elliptic curve cryptography cannot be used in FIPS mode (it’s 
not part of the FIPS module), no matter which version of OpenSSL you use with 
the 1.2 OpenSSL FIPS module.  If you were previously using ECDSA keys in your 
application, you were not using the FIPS module, and any statements about the 
application being FIPS 140 compliant were mistaken, at best.

TOM

On Aug 8, 2014, at 1:59 AM, Gayathri Manoj gayathri.an...@gmail.com wrote:

 Hi Jeffrey,
 
 I used  openssl_fips 1.2 with openssl 0.9.8l. and planning to upgrade 
 openssl-0.9.8l to 0.9.8za with -no-ec option. Please let me know is it break 
 my fips compliance.
 
 Thanks,
 Gayathri
 
 
 On Fri, Aug 8, 2014 at 11:09 AM, Jeffrey Walton noloa...@gmail.com wrote:
 On Fri, Aug 8, 2014 at 1:11 AM, Gayathri Manoj gayathri.an...@gmail.com 
 wrote:
 
  Please let me know openssl-0.9.8za with -no-ec option is fips compliant or
  not.
 No. If you want FIPS validated crypto, then you need one of the
 openssl-fips-*-tar.gz downloads. They produce the FIPS Object Module.
 
 openssl-0.9.8xxx is FIPS capable. It can use the validated
 cryptography if the FIPS Object Module is available.
 __
 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: Making Open SSH FIPS compliant

[Tom Francis]

You might want to start by reading the OpenSSL FIPS Users Guide.  Then go read 
FIPS 140-2, and then read the user’s guide again.  In this case “FIPS” is short 
for “Federal Information Processing Standard Publication 140-2”, and that 
standard is the controlling document (for now, 140-3 should be released 
“soon”).  You can find the official document here: 
http://csrc.nist.gov/publications/PubsFIPS.html  Please note there have been 
some updates since its original release, that in particular affect which 
algorithms are allowed.  Additionally, other NIST publications can affect if 
you can sell your software to US government agencies, as some algorithms, while 
approved for FIPS 140-2, are only approved based on key size, and some 
algorithms have been disallowed depending on why you use it.

This is a complex space with several documents that affect what you can and 
cannot do, and depending on your target audience, you might get away with more 
or less, as exception letters are still sometimes granted (or pretended to be 
indefinite).

But for “how does the call to FIPS_mode_set() make an application FIPS 
compliant?”  It doesn’t.  You certify that your application uses a FIPS 140-2 
compliant security module, and that you use the module according to its 
security policy.  Part of following the security policy is to call 
FIPS_mode_set() appropriately; it’s just one little piece, and probably the 
easiest piece of it. :)  If you’re curious what parts of FIPS 140-2 are 
addressed by the call, well, the self-tests are performed, and some state is 
set such that all crypto will happen using the code in the FIPS module, instead 
of the main OpenSSL code*, along with ensuring that certain algorithms are 
recognized but disabled.

TOM

* There’s a bug in some versions of OpenSSL that mean if you link a FIPS 
capable OpenSSL, you’re always using the routines from the FIPS module, even if 
FIPS mode was not enabled; I don’t recall which versions or if this has been 
fixed.

On Jul 16, 2014, at 1:25 PM, Sadhana sadhana...@gmail.com wrote:

 Along, with this, I am also curious to know, how the  call FIPS_mode_set make 
 an application FIPS compliant.
 I have gone through the below link, 
 http://wiki.openssl.org/index.php/FIPS_mode_set()
 But I am seeking a little more information regarding this.
 
 
 On Wed, Jul 16, 2014 at 7:11 PM, Sadhana [hidden email] wrote:
 Thanks Steve.
 Is there a standard documentation, which says these are FIPS compliant 
 ciphers / macs / kex algorithms.
 
 Meaning I would need to know, if aes128-cbc is FIPS compliant/ aes128-ctr is 
 FIPS compliant.
 Similarly for macs, kex algorithms as well.
 
 
 
 On Wed, Jul 16, 2014 at 4:47 PM, Steve Marquess-3 [via OpenSSL] [hidden 
 email] wrote:
 On 07/15/2014 09:38 AM, Sadhana wrote:
 
  Hello All, 
  
   I have a requirement to make Openssh FIPS compliant. It would be really 
  helpful, if you could answer the 
  below question and correct me if I am wrong. 
  
  I also understand there is a module called as fipscanister.o is introduced 
  in Openssl. 
  This ensures, FIPS compliancy. This also, exposes the API FIPS_mode and 
  FIPS_set_mode. 
  We have already integrated openssl with fipscanister.o. 
  
  Is there any way by which, Openssh  can make use of fipscanister module 
  directly? 
  
  I understand, Openssh needs to call FIPS_mode, FIPS_set_mode to ensure it 
  operates in FIPS mode. 
  I understand, few of the ciphers, MACs, kex algorithms are fips compliant 
  and few others are not. 
  Hence, openssh code has to be modified to allow only those which are fips 
  compliant. 
  
  Are there any more stuff which needs to be done?
 Yes. Converting an application to use the FIPS capable OpenSSL and 
 qualify as using a FIPS 140-2 validated crypto module *can* be as simple 
 as adding a FIPS_mode_set() call. However, modifying OpenSSH for FIPS 
 140-2 compliance is non-trivial as OpenSSH implements a number of 
 cryptographic operations outside of OpenSSL. It's not enough that only 
 cryptographic algorithms allowed by FIPS 140-2 are used, those crypto 
 operations must be performed *within* a validated module. 
 
 Or in other words, an application which hopes to claim to satisfy the 
 USG/DoD requirements for FIPS 140-2 validated cryptography must use 
 validated module(s) for all relevant cryptography. The FIPS capable 
 OpenSSL libraries satisfy that requirement but only if OpenSSL is used 
 exclusively. 
 
 You can find a patch at 
 
 
 http://opensslfoundation.com/export/openssh/openssh-6.0p1.fips-revised.patch
 
 which adapts a now obsolete version of OpenSSH to use the FIPS capable 
 OpenSSL. New inlined cryptography has been added since then so I suspect 
 additional non-trivial work will be necessary. I haven't been keeping 
 track but other newer patches may be available elsewhere. 
 
 Also note than in a U.S. DoD context you'll probably need x.509 support 
 as well (this is available in patches from Roumen Petrov). 
 
 

Re: solaris-x86-cc or solaris-x86-gcc via MACHINE and SYSTEM exports

[Tom Francis]

You should be setting the KERNEL_BITS environment variable.  That works for 
several platforms, including Solaris x86 (although others default to 32, and 
you need to set it to 64 to get a 64-bit build).  As an alternative, (if you’re 
not building the FIPS module) if you know which build configuration to use, you 
can pass it directly to the Configure script, which doesn’t do any detection 
(the detection is done in the config script).  This does assume, of course, 
that your compiler will, by default, create 32-bit executables.  If you’re 
actually on 64-bit Solaris x86, then both Sun (Oracle) cc and GCC will make 
64-bit binaries.  In that case, it gets harder.  I usually just throw a script 
that invokes the compiler with the appropriate compiler option added on (and 
strip out the wrong one, just in case), and make sure the script appears first 
in the path as gcc or cc (depending on which compiler to use). :)

TOM

On Jul 9, 2014, at 3:55 PM, Jeffrey Walton noloa...@gmail.com wrote:

 I'm having trouble setting up solaris-x86-cc and solaris-x86-gcc via
 MACHINE and SYSTEM.
 
 How exactly does one force the use of x86 when compiling for Solaris
 when Configure/config is mis-identifying the system (the
 mis-identification is x86_64).
 
 (And to complicate matters, I don't have access to the machine at the
 moment. This is testing on a different machine).
 
 Thanks in advance.
 
 *
 
 Here's the `uname` that's causing the problems:
 
   SunOS hostname 5.10 Generic_147441-01 i86pc i386 i86pc
 
 *
 
 When I try:
 
export MACHINE=solaris
export RELAEASE=10
export SYSTEM=i686
export BUILD=Solaris; Solaris 10; i686
 
 I get:
 
 ./config
Operating system: solaris-whatever-i686
This system (i686) is not supported. See file INSTALL for details.
 
 *
 
 When I try:
 
export MACHINE=i686
export RELAEASE=10
export SYSTEM=solaris
export BUILD=Solaris; Solaris 10; i686
 
 I get:
 
$ ./config
Operating system: i686-whatever-solaris
Configuring for solaris
Usage: Configure [no-cipher ...] [enable-cipher ...] ...
 
pick os/compiler from:
...
 
 *
 
 I've also tried the x86 and i386 variants.
 __
 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: Reg. type of certificate - CA / EE based on X509_check_ca().

[Tom Francis]

On Jul 7, 2014, at 5:40 AM, Sanjaya Joshi joshi.sanj...@gmail.com wrote:

 Hello,
   My application uses openssl 1.0.0, and it uses X509_check_ca() to find out 
 if an X509 certificate is a CA certificate, or an End-entity (EE) certificate.
 
 The below are the possible return codes.
 
 /* return codes of X509_check_ca():
 * 0 not a CA
 * 1 is a CA
 * 2 basicConstraints absent so maybe a CA
 * 3 basicConstraints absent but self signed V1.
 * 4 basicConstraints absent but keyUsage present and keyCertSign 
 asserted.
 */
 
 My question here is, if we get return code as 4, should we consider this as a 
 CA certificate or an EE certificate ?

It really depends on your use case, I think.  For example, one application I 
worked on had to “import” certificates to aid another process in locating 
certificates and building certificate chains (this goes back a _long_ time 
ago).  For that one, it made more sense to treat such a cert as a CA 
certificate, since it was not uncommon for certificates that had their version 
set to V3 to be missing basicConstraints, and V1 certificates were still quite 
popular.  The app needed to be able to import such certificates into locations 
for most efficient access (and putting a cert that should be used in building a 
chain into a location that wasn’t considered for building the chain would be 
really bad).  If your use case is significantly different, you could go either 
way, or maybe even reject such certificates entirely.

TOM

 Any quick support in this regard is much appreciated.
 Regards,
 Sanjaya

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Where is PKCS7_free defined?

[Tom Francis]

On May 25, 2014, at 10:15 AM, Han Sooloo hansoo...@gmail.com wrote:

 Trying to understand how the crl2p7.c application allocates PKCS7 pointers.  
 I see the PKCS7_new() function and it makes sense.
 
 However, I cannot find the definition of PKCS7_free().  The only place it 
 shows up is in libeay.num as PKCS7_free  444 
 EXIST::FUNCTION:”
 
 2 questions:
 1. What does the above declaration in libeay.num mean?
 2. What is the definition of PKCS7_free()?  How does it free memory pointed 
 to by a PKCS7 data structure?

Most of the structures that are defined as ASN.1 structures (including PKCS7) 
have methods like _free implemented through a macro.  You can search for the 
definition of the IMPLEMENT_ASN1_FUNCTIONS macro (in crypto/asn1/asn1t.h) for 
more info, but IIRC, it uses ASN1_item_free() which ultimately uses 
OPENSSL_free() for (nearly?) everything inside (some structures (but not, IIRC, 
PKCS7) will also have OPENSSL_cleanse invoked proper to releasing the memory, 
and there’s a patch that will apply that more frequently).  Some structures use 
their own customer _new or _free methods, but I didn’t think PKCS7 used a 
custom _new (and I don’t see one in 1.0.1g).  In general, though, if you’re 
manipulating the members of the structure directly, you should be sure to 
allocate any buffers with OPENSSL_malloc() before assigning them to members of 
the structure, as PKCS7_free will assume it can release the buffers with 
OPENSSL_free().  I always find it simpler to not touch any members directly, 
but use the methods and macros defined in pkcs7.h.  They should duplicate any 
buffers that PKCS7_free() expects to free on its own, so it’ll be safe to 
release your buffers without worry.

TOM

 
 __
 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: encrypt - salt

[Tom Francis]

On May 16, 2014, at 4:14 AM, Hooman Fazaeli hoomanfaza...@gmail.com wrote:

 On 5/16/2014 2:15 AM, Dave Thompson wrote:
 EVP_BytesToKey implements (a tweak on) the original PKCS#5, which derived a 
 key and IV
 by iterated hashing of a (reusable but secret) password with random (i.e. 
 unique) salt.
 Given random salt this gives effectively random IV, but is unnecessarily 
 complicated.
  
 This was recognized as a not terribly good plan, and the improved PBKDF2 in 
 PKCS#5v2
 derives only the key in a slightly different way (iterated *HMAC* with salt 
 *cumulated*)
 leaving the IV, if any, as plain random outside the scope of the PBKDF2 
 primitive.
 OpenSSL does implement PBKDF2, and can use it for PKCS#8 and PKCS#12 etc.,
 but kept BytesToKey for compatibility with existing ‘enc’ files and ‘legacy’ 
 (pre PKCS#8) keys.
 (Which don’t even really use the iteration feature; they are hardcoded 1!)
  
 Using BytesToKey with random salt to generate the IV is a waste of time,
 and using it with fixed salt violates its specification. Just use random IV.
 Unless you don’t trust your RNG. But in that case you’re better off fixing or
 replacing the RNG, not trying weird things to prop it up.
  
 BytesToKey (like PBKDF1) uses the one iteration count to produce data which 
 is returned
 for both key and IV. It does additional round(s) if and only if necessary, a 
 PBKDF2-like tweak
 not in standard PBKDF1, but still using the same count.
  
 
 Which openssl function does key derivation based on PKCS#5v2?

Search the crypto/ subdirectory for occurrences of PKCS5_pbkdf2_set.  
Basically, you use PKCS5_pbkdf2_set() to create an X509_ALGOR* to be passed to 
EVP_PBE_CipherInit (actually, you’d pass the algorithm member of the returned 
X509_ALGOR* as the first parameter to EVP_PBE_CipherInit), which can initialize 
an EVP_CIPHER_CTX* with the derived key so you can start encrypting/decrypting. 
 If you really need only the key, you might want to do something differently, 
since the actual key generation is not in a public method (IIRC).

TOM

 -- 
 
 Best regards.
 Hooman Fazaeli
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [1.0.1] Nested CMS structures

[Tom Francis]

On May 3, 2014, at 2:41 PM, Kevin Le Gouguec kevin.le-goug...@insa-lyon.fr 
wrote:

 Using asn1parse, I got this:
 
0:d=0  hl=4 l=3980 cons: SEQUENCE  
4:d=1  hl=2 l=   9 prim:  OBJECT:pkcs7-envelopedData
   15:d=1  hl=4 l=3965 cons:  cont [ 0 ]
   19:d=2  hl=4 l=3961 cons:   SEQUENCE  
   23:d=3  hl=2 l=   1 prim:INTEGER   :00
   26:d=3  hl=4 l= 304 cons:SET   
   30:d=4  hl=4 l= 300 cons: SEQUENCE  
   34:d=5  hl=2 l=   1 prim:  INTEGER   :02
   37:d=5  hl=2 l=  20 prim:  cont [ 0 ]
   59:d=5  hl=2 l=  13 cons:  SEQUENCE  
   61:d=6  hl=2 l=   9 prim:   OBJECT:rsaEncryption
   72:d=6  hl=2 l=   0 prim:   NULL  
   74:d=5  hl=4 l= 256 prim:  OCTET STRING  [HEX DUMP]:SNIP ENCRYPTED 
 KEY
  334:d=3  hl=4 l=3646 cons:SEQUENCE  
  338:d=4  hl=2 l=   9 prim: OBJECT:pkcs7-data
  349:d=4  hl=2 l=  29 cons: SEQUENCE  
  351:d=5  hl=2 l=   9 prim:  OBJECT:aes-256-cbc
  362:d=5  hl=2 l=  16 prim:  OCTET STRING  [HEX DUMP]:SNIP IV
  380:d=4  hl=4 l=3600 prim: cont [ 0 ]
 
 ator
 Info, SET of Recipient Info, ... }. So I guess here the version number is 0?
 This is weird, since I'm using a Subject Key Identifier: this condition must
 set the RecipientInfo's version field to 2 (which is happening), which in 
 turn should
 make the EnvelopedData's version also 2 (which is not happening).
 
 ... Weird.

Yeah, that looks wrong to me, too.  It should be 2.  It probably doesn’t cause 
any trouble most of the time, since the idea is that you won’t check the 
version number unless you get a decode error.  Perhaps someone can confirm 
we’re not missing something?  Here’s the bit of the RFC (from section 6.1) that 
I believe indicates the version should be 2:


   The fields of type EnvelopedData have the following meanings:

  version is the syntax version number.  The appropriate value
  depends on originatorInfo, RecipientInfo, and unprotectedAttrs.
  The version MUST be assigned as follows:

 IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
 THEN version is 4
 ELSE
IF ((originatorInfo is present) AND
   (any version 2 attribute certificates are present)) OR
   (any RecipientInfo structures include pwri) OR
   (any RecipientInfo structures include ori)
THEN version is 3
ELSE
   IF (originatorInfo is absent) AND
  (unprotectedAttrs is absent) AND
  (all RecipientInfo structures are version 0)
   THEN version is 0
   ELSE version is 2



 
 
 (Parsing ASN.1 stuff) 
 
 Yup, I think I got the idea of how ASN.1 works, and I'm starting to be pretty
 familiar with the CMS RFC (and its various updates). The thing is, I'm having
 trouble finding a decent parser ; I've tried compiling the CMS ASN.1 spec 
 into C
 classes with e.g. asn1c, but all the ASN.1 compilers I've tried choke on the
 syntax as it is written in the RFC (I also tried the spec from RFC 6268 but 
 the
 programs still can't compile it).

I thought asn1c (and most others) had been updated to use the latest syntax, 
but I’m guessing that’s not the case. The older syntax is very similar, I 
wouldn’t expect it to be very hard to update it, just be aware that the reason 
for the newer syntax was to make some things more explicit, where different 
ASN.1 compilers would handle the same syntax slightly differently.

 Should I bother using OpenSSL's ASN.1 API or should I continue trying to get 
 an
 ASN.1 compiler to work with the CMS spec?

I typically just use OpenSSL, even if I’m not using anything else from OpenSSL. 
 According to the docs, there’s stuff it doesn’t handle, but the limitations 
have never bothered me (not that my needs have been complex!).  It also means I 
need to set things up using OpenSSL’s macros rather than have it compile ASN.1 
syntax like asn1c would do, but I generally dislike dealing with generated 
source code, unless it’s Java.  :)

TOM

snip__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [1.0.1] Nested CMS structures

[Tom Francis]

On May 2, 2014, at 3:19 AM, Kevin Le Gouguec kevin.le-goug...@insa-lyon.fr 
wrote:

 (tl;dr : see questions at the end)
 
 I'm trying to build nested CMS structures, as in, having a file F, a signer S 
 and a recipient R, I want to build a CMS-compliant message M which looks like:
 
 M = SignedData(ECI, SignerInfo(S))
 
 ECI = EncapsulatedContentInfo( EnvelopedData( RecipientInfo(R) )
 
 Where RecipientInfo(R) contains:
 [ F ] = encrypted file, [ K ] = file-encryption key, encrypted with R's 
 public key.
 
 Now the code compiles, I figure I can parse that back, but when I run 
 `openssl cms` or `openssl asn1parse` on the generated DER file, the whole 
 EnvelopedData show up as one big OctetString. Is that normal?

Yes, the idea is that you’d run your process over the data in multiple passes, 
so if you’re using the openssl command line program, you’d do the first pass to 
verify the signature and dump the enveloped data to a temp file*, and then run 
openssl again to decrypt the data from the temp file.  The openssl command line 
isn’t set up to handle CMS structures recursively — that’s also why if you use 
the command line to create this, you’d need to invoke openssl twice, the first 
time to encrypt, the second time to sign (in your case).

 Here's my code (all error checking has been left out for brevity):
 
/* Make EnvelopedData structure */
 
BIO* in = BIO_new_file(in_path, rb);
 
int flags = CMS_BINARY | CMS_USE_KEYID | CMS_PARTIAL;
 
CMS_ContentInfo* edata = CMS_encrypt(NULL, NULL, cipher, flags);
 
CMS_RecipientInfo* r_info = CMS_add1_recipient_cert(edata, r_cert, flags);
 
CMS_final(edata, in, NULL, flags);
 
BIO* tmp = BIO_new(BIO_s_mem());
i2d_CMS_bio(tmp, edata);/* [1] */
 
/* Make SignedData structure */
 
flags|= CMS_NOSMIMECAP | CMS_NOCERTS;
 
CMS_ContentInfo* sdata = CMS_sign(NULL, NULL, NULL, NULL, flags);
 
ASN1_OBJECT* ectype_edata = OBJ_nid2obj(NID_pkcs7_enveloped);
 
CMS_set1_eContentType(sdata, ectype_edata);
 
CMS_SignerInfo* s_info =
  CMS_add1_signer(sdata, s_cert, s_key, NULL, flags);
 
CMS_SignerInfo_sign(s_info);
 
CMS_final(sdata, tmp, NULL, flags);
 
BIO* out = BIO_new_file(out_path, wb);
 
i2d_CMS_bio(out, sdata);
 
BIO_flush(out);
 
 Now, here's the output from cms:
 
 CMS_ContentInfo: 
  contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
  d.signedData: 
version: 3
digestAlgorithms:
algorithm: sha1 (1.3.14.3.2.26)
parameter: ABSENT
encapContentInfo: 
  eContentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
  eContent: 
 LARGE OCTET STRING, A BIT LARGER THAN THE FILE 
certificates:
  EMPTY
crls:
  EMPTY
signerInfos:
version: 3
d.subjectKeyIdentifier: 
   KEY ID IS HERE 
digestAlgorithm: 
  algorithm: sha1 (1.3.14.3.2.26)
  parameter: ABSENT
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
  OBJECT:pkcs7-envelopedData (1.2.840.113549.1.7.3)
 
 ALSO UTC TIME WHATEVER 
 
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
  OCTET STRING:
 HASH GOES HERE 
signatureAlgorithm: 
  algorithm: ecdsa-with-SHA1 (1.2.840.10045.4.1)
  parameter: ABSENT
signature: 
   SIG GOES HERE 
unsignedAttrs:
  EMPTY
 
 If I output what the BIO at [1] contains, I see this:
 
 CMS_ContentInfo: 
  contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
  d.envelopedData: 
version: ABSENT
originatorInfo: ABSENT
recipientInfos:
  d.ktri: 
version: 2
d.subjectKeyIdentifier: 
   KEY ID IS HERE 
keyEncryptionAlgorithm: 
  algorithm: rsaEncryption (1.2.840.113549.1.1.1)
  parameter: NULL
encryptedKey: 
   256-BYTES LONG OCTET STRING, SINCE RSA-2048 
encryptedContentInfo: 
  contentType: pkcs7-data (1.2.840.113549.1.7.1)
  contentEncryptionAlgorithm: 
algorithm: aes-256-cbc (2.16.840.1.101.3.4.1.42)
parameter: OCTET STRING:
   16 BYTES IV 
  encryptedContent: 
   LARGE OCTET STRING, ABOUT THE SIZE OF MY FILE PLUS AES PADDING I 
 FIGURE 
unprotectedAttrs:
  EMPTY
 
 
 So I guess my questions are:
 
 - Does the code look OK to people who regularly use the API?

It (mostly) looks like what I’d expect — see below.

 - Should I be worried the EnvelopedData show up as one big OctetString when 
 cms/asn1parse parse the SignedData?

No; I’d be concerned if it didn’t show up that way — that’s how CMS is defined 
to work.

 - Should I be worried the version field in the EnvelopedData shows ABSENT?

I’ll let someone else answer that; I would have expected version to be set 
properly.  I don’t recall seeing anything that would suggest you need to set 
the version yourself, since as you point out, 

Re: Java and C/OpenSSL

[Tom Francis]

 On Apr 26, 2014, at 6:25 PM, Anant Rao a...@noknok.com wrote:
 
 Hi,
 
 I see the doc. But, I'm afraid to say my question is still unanswered. Is 
 this function (PKCS5_PBKDF2_HMAC) supposed to generate same or diff output 
 over multiple calls with the same input? I see the latter and I want to know 
 what, if any, I'm doing incorrect.

Yes, the PBKDF2 implementation will output a consistent key with the same 
inputs. It would be rather pointless otherwise. :). It will also output the 
same key as the Java implementation it they have matching inputs (I write from 
experience here). If you post your code (more than just the actual call) for 
both, someone can tell what's wrong.

 Thanks a lot for your help/favor!
 Anant
 
 
 On Sat, Apr 26, 2014 at 2:12 PM, Matt Caswell fr...@baggins.org wrote:
 On 26 April 2014 20:38, Jeffrey Walton noloa...@gmail.com wrote:
  On Sat, Apr 26, 2014 at 3:18 PM, Anant Rao a...@noknok.com wrote:
  I'm doing password encryption (and decryption) in Java. I need to port 
  this
  to C.
  In Java, I'm doing this:
 
  PBEKeySpec (somepassphrase, some_salt, some iterations, 128
  /*key_length*/);
  Algorithm is PBKDF2WithHmacSHA1
 
  If I generate a secret key with the above data, I get the same output with
  multiple runs of the program.
 
  In C, I tried doing something similar using OpenSSL:
 
  EVP_BytesToKey(EVP_aes_128_cbc(), EVP_sha1(), salt, passphrase,
  strlen(passphrase), nrounds, key, NULL /*iv*/);
  How about PKCS5_PBKDF2_HMAC?
 
  There are no docs on it, but a patch is sitting in RT at
  https://rt.openssl.org/Ticket/Display.html?id=3293user=guestpass=guest.
  Download the POD file and open it with a text editor.
 
 
 This is now in git:
 
 http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6bcc4475fcdb2ea5daae80cbb2a5a5fcf677ac23
 
 Matt
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 
 
 -- 
 
 Anant Rao
 Server Lead
 D  / a...@noknok.com
 
 
 
 Nok Nok Labs Inc.
 4151 Middlefield Road, Suite 200
 Palo Alto, CA 94303
 T +1 650 433 1300
 i...@noknok.com
 www.noknok.com
 
  
 
  
 

Re: How to include intermediate in pkcs12?

[Tom Francis]

On Apr 24, 2014, at 8:21 AM, Edward Ned Harvey (openssl) 
open...@nedharvey.com wrote:

 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
 us...@openssl.org] On Behalf Of Dave Thompson
 
 - the truststore if -CAfile and/or -CApath specified IF NEEDED
 
 Thank you very much for your awesome detailed answer.  This answers a lot of 
 questions, but I am left with a new one:
 
 I use openssl on a lot of different platforms, and it always seems to be 
 built differently...  OSX native, OSX homebrew, various linuxes, openindiana, 
 cygwin, nuGet in Visual Studio, etc.  I don't know if these builds 
 universally include any set of root CA's, and sometimes I can find a 
 directory to answer my question, sometimes not.

OpenSSL itself does not include any certificates at all.  The root certificates 
installed on a system are unrelated to the version of OpenSSL or how OpenSSL 
was compiled.

 Is there some way I can make openssl tell me the list of roots it has?  Or 
 tell me the directory (directories) that it searches?

For the second question, no; there’s no location that OpenSSL (either the 
library or the command line app) will search automatically — you have to 
specify that on your own, with -CApath (or -CAfile).  For the first question, 
there are a few different possibilities, but remember that you have to tell 
OpenSSL where to look, and what to look for. :)  You could, e.g., use ‘openssl 
x509 -noout -text -in file’ for a bunch of different certificate files in DER 
or PEM format (it’ll even work if there are multiple certificates in file).

 It seems, to answer my original question, *if* I can trust that openssl on 
 the platform that I'm using actually as a complete-ish set of root CA's, then 
 the best and easiest way to build the pfx will be:
   openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in 
 mycert.crt -certfile intermediate.crt
   (Correct?)

If the OS has a complete-ish set of root certificates installed somewhere, you 
can use a command line like that, but you probably want to use -CApath to 
specify the directory where the root certificates are installed.

 And if the above doesn't automatically include the root CA for my chain (or 
 if I just like doing it explicitly), then I can do this:
   openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in 
 mycert.crt -certfile intermediate.crt -CAfile ca.crt
   (Correct?)

That’s likely to be more reliable everywhere. :)

 Alternatively, I could
   cat mycert.crt intermediate.crt ca.crt  mychain.crt
   openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in 
 mychain.crt
   (Correct?)

This would also work, but unless you’ve got another reason to stick all of the 
certificates in the chain into a single file first, it’s likely to be more 
trouble than it’s worth.  I usually put my root and any intermediates into a 
single file and use -CAfile to specify the intermediate(s) (if any) and root 
when I’m generating certificates and packaging them in PKCS#12 for distribution 
(e.g. to send to a Windows user).  But I think the question of what’s “best” is 
dependent on what you’re doing, and how you like to do things. :)

TOM


 Thanks...
 __
 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: CRL generating server, not from command line

[Tom Francis]

On Mar 18, 2014, at 2:19 PM, Clesmon University www.clemson@gmail.com 
wrote:

 Hello:
 
 What I can find online or in book Network security with OpenSSL is using 
 command line to generte a CRL.  However, what I want to do is to let my 
 server receive a serial number from outside interface and generate a CRL.  I 
 have looked many place and never find a article to mention it.  
 
 Can anyone help or show me how to do it?  

It depends a little on how you track your CRLs and certificates (or how you 
want to do it).  Basically, you’ll need to create an X509_CRL and an 
X509_REVOKED, and use X509_CRL_add0_revoked(), and then don’t forget to sign 
the new CRL (and add any extensions you need/want).  You should save the serial 
number or CRL somewhere, so that future updates will still show the previously 
revoked certificates as revoked.  If you look at the openssl source code, at 
apps/ca.c, you’ll see how the openssl command line deals with this (hint: it 
creates/updates a file that tracks the revoked certificate serial numbers and 
other relevant info, then uses another command to generate CRLs with each 
revoked certificate serial number as requested).  If go the route of keeping 
just the previously generated CRL, you’ll probably want to use 
d2i_X509_CRL/i2d_X509_CRL (or maybe one of the PEM/BIO/fp variants), and when 
revoking something new, create a new CRL with all of the original data.  I seem 
to recall that trying to use the same X509_CRL structure was more trouble than 
it was worth, so I always created a fresh one.  Also, be sure you know your use 
cases well before trying to decide if you want to generate a new CRL every time 
or not.  That may be necessary, or that might be wasted CPU cycles and disk 
space. :)


TOM

snip__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org