date:20160209

Re: [openssl-users] FIPS Object Module v2.0 and openssl security patches

2016-02-09 Thread Steve Marquess

On 02/09/2016 03:19 PM, cloud force wrote:
> Hello everyone,
> 
> Would the FIPS Object Module v2.0 supposed to only work with the vanilla
> openssl library? If I apply the security patches to the openssl library,
> should the FIPS Object Module v2.0 still work without problems?

You should patch OpenSSL whether you use it with the FIPS module or not.

>From the perspective of the FIPS 140-2 validation, stock OpenSSL is just
application code and is out of scope. So you can patch/hack OpenSSL
proper as much as you want; as long as the intact FIPS module is built
per the mandated process its FIPS-ness is unaffected by OpenSSL.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

2016-02-09 Thread Salz, Rich


   // Generates Garbage
   memcpy(encbuf, encbuf+100, enclen); 

For overlapping copies you are supposed to use memmove.

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

[openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

2016-02-09 Thread Mark Parr

I have a program that for some time now under SUSE Linux Enterprise Server has 
worked fine.  Recently, it was moved over to an OpenSUSE 13.2 system and a 
problem was encountered.  The program interfaces to a 3rd party  and data is 
received into our program where the data block consists of some header 
information and AES encrypted data.  Using the OpenSSL libcrypto library we 
successfully interfaced to this system under SLES.  However, under OpenSUSE we 
consistently see the an error where the end of the decrypted data contains 
garbage.  I have identified where the problem happens and have a work around 
but in looking at the code, I don’t see why there would be a problem.

 

I have created a test program that simulates the problem.  The test program 
works fine under SUSE Linux Enterprise Server 11 and on a Red Hat 7.2 
Enterprise Linux but fails on OpenSUSE 13.2 using different release levels of 
the OpenSSL libraries.  Under SLES and Red Hat, the decrypted data is cleanly 
returned.  Under OpenSUSE, most of the data is decrypted cleanly except for 
some garbage that appears toward the end of the data block.  The returned block 
of data is correct, then contains some garbage, and then ends correct.  The 
code for my sample program is below but the line causing the problem is a 
memcpy() where I shift the encrypted data to the front of the data block for 
processing.  The line in my sample program is below:

 

   // Generates Garbage

   memcpy(encbuf, encbuf+100, enclen); 

 

If I move the encrypted data to temporary buffer before moving it to the start 
of the encbuf, the garbage is not generated.

 

   // This does not generate garbage

   memcpy(tmpbuf, encbuf+100, enclen); 

   memcpy(encbuf, tmpbuf, enclen); 

 

My sample program takes a defined buffer of clear text, encrypts it using a key 
and IV and then decrypts it back and displays the result.  Condensed code is as 
follows:

 

#include   

#include  

#include  

#include  

#include

#include   

#include   



#include 



#define EVP_DECRYPT   0 

#define EVP_ENCRYPT   1

 

char clrbuf[10];

char encbuf[10];

char tmpbuf[10];

int clrlen; 

int enclen; 

 

char enckey[1024];  

unsigned char enciv[16];

 

main()

{

   int rc;

 

   // Set clear text to 50 lines of text

   sprintf(clrbuf,   

 "0001this is a test this is a test this is a test this is a test\n" \

 "0002this is a test this is a test this is a test this is a test\n" \

 "0003this is a test this is a test this is a test this is a test\n" \

 // etc etc etc…….

 "0048this is a test this is a test this is a test this is a test\n" \

 "0049this is a test this is a test this is a test this is a test\n" \

 "0050this is a test this is a test this is a test this is a test\n"  

 

   sprintf(enckey, "this is the key this is the key ");

   sprintf(enciv, "1234567890123456");

 

   // Encrypt the data and simulate a 100 byte header by returning encrypted 
data 100 bytes into the data block

   //

   memcpy(encbuf, "Some header stuff that will need to be removed", 46);

   rc = evp_aes256_cbc(clrbuf, strlen(clrbuf), encbuf+100, , enckey, 
enciv, EVP_ENCRYPT);  

 

   // Now remove the header by shifting the encrypted data to the start of the 
data block and decrypt

   // This is where doing the memcpy() as coded in OpenSUSE results in garbage 
at the end of clrbuf

   // but everything is returned correctly in SLES and Red Hat

   //

   // This work fines on all OSes:

   // memcpy(tmpbuf, encbuf+100, enclen); 

   // memcpy(encbuf, tmpbuf, enclen); 

 

   memcpy(encbuf, encbuf+100, enclen); 

   rc = evp_aes256_cbc(encbuf, enclen, clrbuf, , enckey, enciv, 
EVP_DECRYPT);

 

   printf("Decrypt: rc=%d  EncLen=%d  ClrLen=%d\n", rc, enclen, clrlen);

   printf("Data:\n\n<\n%s\n>\n\n", clrbuf); 
}

 

//  



evp_aes256_cbc(char *InBuf, int InLen, char *OutBuf, int OutLen, char *Key, 
char *IV, int EncryptFlag)  

{   

   EVP_CIPHER_CTX ctx;  

   int padlen;  



   EVP_CIPHER_CTX_init();   



   if (! EVP_CipherInit_ex(,

[openssl-users] Is the structure of this CMS object correct?

2016-02-09 Thread Stephan Mühlstrasser


Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe 
Acrobat) with OpenSSL 1.0.2d:


$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey 
atssecp521r1.key -recip atssecp521r1.pem

Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding 
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding 
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.kari, 
Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding 
routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo


The full dumpasn1 output of the file "recipient.bin" is below at the end 
of the message. Is this a correct CMS object?


If I compare this to the structure of a CMS object that was generated by 
OpenSSL itself, there's a difference in the structure of the 
RecipientInfos object. If I understand it correctly, this is the start 
of the RecipientInfos object (starting at line 6 of the dumpasn1 output):


   SET {
 [1] {
   SEQUENCE {
 INTEGER 3
 ...

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion,  -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }

If I dump a CMS object that was created with OpenSSL's CMS tool with the 
same certificate as the problematic one, the structure of the 
RecipientInfos object looks like this:


   SET {
 [1] {
   INTEGER 3
   ...

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

Another issue in the Acrobat-generated CMS object is the top-level 
CMSVersion in the EnvelopedData object being 0. I believe this is wrong 
and should be 2, but apparently OpenSSL doesn't care.


Full output of dumpasn1 for "recipient.bin" file:

 SEQUENCE {
   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
   [0] {
 SEQUENCE {
   INTEGER 0
   SET {
 [1] {
   SEQUENCE {
 INTEGER 3
 [0] {
   [1] {
 SEQUENCE {
   SEQUENCE {
 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
 }
   BIT STRING
   04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
   5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
   1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
   55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
   9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
   3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
   B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
   93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
   [ Another 5 bytes skipped ]
   }
 }
   }
 [1] {
   OCTET STRING E5 38 52 B1 13 7C 44 40
   }
 SEQUENCE {
   OBJECT IDENTIFIER '1 3 132 1 11 3'
   SEQUENCE {
 OBJECT IDENTIFIER
   aes256-wrap (2 16 840 1 101 3 4 1 45)
 }
   }
 SEQUENCE {
   SEQUENCE {
 SEQUENCE {
   SEQUENCE {
 SET {
   SEQUENCE {
 OBJECT IDENTIFIER countryName (2 5 4 6)
 PrintableString 'DE'
 }
   }
 SET {
   SEQUENCE {
 OBJECT IDENTIFIER localityName (2 5 4 7)
 UTF8String 'Munich'
 }
   }

Re: [openssl-users] Is the structure of this CMS object correct?

2016-02-09 Thread Erwann Abalea

Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser 
> a écrit :

Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe Acrobat) with 
OpenSSL 1.0.2d:

$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey atssecp521r1.key 
-recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding 
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested 
asn1 error:tasn_dec.c:336:Field=d.kari, Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding 
routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

The full dumpasn1 output of the file "recipient.bin" is below at the end of the 
message. Is this a correct CMS object?

If I compare this to the structure of a CMS object that was generated by 
OpenSSL itself, there's a difference in the structure of the RecipientInfos 
object. If I understand it correctly, this is the start of the RecipientInfos 
object (starting at line 6 of the dumpasn1 output):

  SET {
[1] {
  SEQUENCE {
INTEGER 3
…

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
   ktri KeyTransRecipientInfo,
   kari [1] KeyAgreeRecipientInfo,
   kekri [2] KEKRecipientInfo,
   pwri [3] PasswordRecipientinfo,
   ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
   version CMSVersion,  -- always set to 3
   originator [0] EXPLICIT OriginatorIdentifierOrKey,
   ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
   keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
   recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was changed 
between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori elements are 
associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
 issuerAndSerialNumber IssuerAndSerialNumber,
 subjectKeyIdentifier [0] SubjectKeyIdentifier,
 originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
 algorithm AlgorithmIdentifier,
 publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with the same 
certificate as the problematic one, the structure of the RecipientInfos object 
looks like this:

  SET {
[1] {
  INTEGER 3
  …

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

This is the correct behavior of an IMPLICIT tag.

Another issue in the Acrobat-generated CMS object is the top-level CMSVersion 
in the EnvelopedData object being 0. I believe this is wrong and should be 2, 
but apparently OpenSSL doesn't care.

Full output of dumpasn1 for "recipient.bin" file:

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
  [0] {
SEQUENCE {
  INTEGER 0
  SET {
[1] {
  SEQUENCE {

This is wrong, the SEQUENCE is to be hidden by the [1] tag.

INTEGER 3
[0] {

The [0] introduces the originator element, of type OriginatorIdentifierOrKey, 
it’s EXPLICIT.

  [1] {
SEQUENCE {

Also wrong, the [1] here should be IMPLICIT and hide the SEQUENCE tag of the 
OriginatorPublicKey structure.

  SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
}
  BIT STRING
  04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
  5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
  1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
  55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
  9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
  3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
  B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
  93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
  [ Another

Re: [openssl-users] FIPS building scripts does NOT work for iOS >=7

2016-02-09 Thread Steve Marquess

On 02/08/2016 10:11 PM, Yang Hong wrote:
> Hello Steve.
> 
> Thank you very much for your quick response.
> 
> I have tried different approaches to build FIPS module, according to the
> testing instructions of iOS 7.1 and iOS 8.1. Unfortunately I failed for
> all the FIPS packages for iOS >= 7, i.e., openssl-fips-2.0.8.tar,
> openssl-fips-2.0.9.tar, openssl-fips-2.0.10.tar, openssl-fips-2.0.11.tar. 
> 
> Apple Mac OS has been automatically updated to the new version. I failed
> to recover it to the old version.
>

Yeah, that's one of the problems with FIPS testing for OS X. We almost
always have to tweak the build process for new OS X and/or Xcode versions.

The build process we used and documented for the formal validation
testing can only be expected to work for exactly the same version of OS
X and Xcode we used. That ties with WinCE/EC as the most fragile and
challenging of FIPS platforms to build for.

> ..
>
> I still can not solve the issues.
> 
> ***
> 
> I have used Beyond compare 4 to check the difference between
> openssl-1.0.2f/config (or Configure) and openssl-fips-2.0.11/config (or
> Configure). I do NOT know how to modify the setenv-ios-11.sh to generate
> OpenSSL FIPS module for iOS >=8 under the new Mac OS available from
> Apple website. 
> 
> Would you shed some light on how to modify the building script for iOS
>>=8? Thank you very much.

Unfortunately I can't; I've let our Apple developer subscription lapse
and can't justify spending time on this until/if we hear from a new OS X
or iOS platform sponsor (which probably will happen eventually). Even
when I do work on such testing I usually have to call on my smarter
colleagues for assistance.

There are others who may be able to help, for instance Jeff Walton.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is the structure of this CMS object correct?

2016-02-09 Thread Stephan Mühlstrasser


Bonjour Erwann,

Am 09.02.16 um 11:53 schrieb Erwann Abalea:

Bonjour,


Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser > a écrit :
...

  SET {
[1] {
  SEQUENCE {
INTEGER 3
…


This is the expression of an EXPLICIT tag.


I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
   ktri KeyTransRecipientInfo,
   kari [1] KeyAgreeRecipientInfo,
   kekri [2] KEKRecipientInfo,
   pwri [3] PasswordRecipientinfo,
   ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
   version CMSVersion,  -- always set to 3
   originator [0] EXPLICIT OriginatorIdentifierOrKey,
   ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
   keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
   recipientEncryptedKeys RecipientEncryptedKeys }


See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was
changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori
elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier,
  originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  publicKey BIT STRING }



If I dump a CMS object that was created with OpenSSL's CMS tool with
the same certificate as the problematic one, the structure of the
RecipientInfos object looks like this:

  SET {
[1] {
  INTEGER 3
  …



So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present
here.


This is the correct behavior of an IMPLICIT tag.


many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" 
command. Do I understand it correctly then that the input file is 
neither a correct PKCS#7 file nor a correct CMS file?


--
Stephan

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

Re: [openssl-users] Is the structure of this CMS object correct?

2016-02-09 Thread Erwann Abalea

Bonjour Stephan,


Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser 
> a écrit :

Am 09.02.16 um 11:53 schrieb Erwann Abalea:
Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser 

> a écrit :
...

 SET {
   [1] {
 SEQUENCE {
   INTEGER 3
   …

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo,
  pwri [3] PasswordRecipientinfo,
  ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 3
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was
changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori
elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
 issuerAndSerialNumber IssuerAndSerialNumber,
 subjectKeyIdentifier [0] SubjectKeyIdentifier,
 originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
 algorithm AlgorithmIdentifier,
 publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with
the same certificate as the problematic one, the structure of the
RecipientInfos object looks like this:

 SET {
   [1] {
 INTEGER 3
 …

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present
here.

This is the correct behavior of an IMPLICIT tag.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" command. 
Do I understand it correctly then that the input file is neither a correct 
PKCS#7 file nor a correct CMS file?

PKCS#7 and CMS are pretty much interchangeable.
Here, your file is strictly not a PKCS#7v1.5, because in this version, 
RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).

How did you generate this structure? Adobe Acrobat?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is the structure of this CMS object correct?

2016-02-09 Thread Stephan Mühlstrasser


Am 09.02.2016 um 16:39 schrieb Erwann Abalea:

Bonjour Stephan,
...



I can also not decrypt the recipient.bin file with the "openssl smime"
command. Do I understand it correctly then that the input file is
neither a correct PKCS#7 file nor a correct CMS file?


PKCS#7 and CMS are pretty much interchangeable.
Here, your file is strictly not a PKCS#7v1.5, because in this version,
RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).

How did you generate this structure? Adobe Acrobat?


Yes, this structure was generated with Adobe Acrobat XI (document 
encrypted with "certificate security").


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

Re: [openssl-users] FIPS Object Module v2.0 and openssl security patches

2016-02-09 Thread Kyle Hamilton

On 2/9/2016 12:29 PM, Steve Marquess wrote:
> On 02/09/2016 03:19 PM, cloud force wrote:
>> Hello everyone,
>>
>> Would the FIPS Object Module v2.0 supposed to only work with the vanilla
>> openssl library? If I apply the security patches to the openssl library,
>> should the FIPS Object Module v2.0 still work without problems?
> You should patch OpenSSL whether you use it with the FIPS module or not.
>
> From the perspective of the FIPS 140-2 validation, stock OpenSSL is just
> application code and is out of scope. So you can patch/hack OpenSSL
> proper as much as you want; as long as the intact FIPS module is built
> per the mandated process its FIPS-ness is unaffected by OpenSSL.
>
> -Steve M.
>

...with the caveat that you cannot patch the stock OpenSSL in such a way
that any crypto operations are done by anything other than the FIPS
module, if you want to maintain the FIPS-ness of the systems you build
using it.  Formatting and processing of (including memory management
for) data that is encrypted or decrypted by the FIPS module is fair
game, which includes pretty much all of the security holes that have
happened to date in the OpenSSL library.

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

Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

2016-02-09 Thread Mark Parr

Thanks, Rich.

That fixed things.  Obviously not familiar w/ memmove() or the memcpy() issue 
w/ overlapping data area.

Thanks again.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: Tuesday, February 09, 2016 2:44 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 
13.2


   // Generates Garbage
   memcpy(encbuf, encbuf+100, enclen); 

For overlapping copies you are supposed to use memmove.

-- 
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] FIPS Object Module v2.0 and openssl security patches

2016-02-09 Thread cloud force

Hello everyone,

Would the FIPS Object Module v2.0 supposed to only work with the vanilla
openssl library? If I apply the security patches to the openssl library,
should the FIPS Object Module v2.0 still work without problems?

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

Re: [openssl-users] FIPS Object Module v2.0 and openssl security patches

Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

[openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

[openssl-users] Is the structure of this CMS object correct?

Re: [openssl-users] Is the structure of this CMS object correct?

Re: [openssl-users] FIPS building scripts does NOT work for iOS >=7

Re: [openssl-users] Is the structure of this CMS object correct?

Re: [openssl-users] Is the structure of this CMS object correct?

Re: [openssl-users] Is the structure of this CMS object correct?

Re: [openssl-users] FIPS Object Module v2.0 and openssl security patches

Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

[openssl-users] FIPS Object Module v2.0 and openssl security patches

12 matches

Site Navigation

Mail list logo

Footer information