[openssl-users] Documentation for Integrating New Cipher Creation Request

[Schmicker, Robert]

Hello,

Over the past several months through trial and error I have at last been able 
to integrate a new symmetric cipher into OpenSSL. After following this email 
chain for these past months I’ve noticed that once in a blue moon other users 
would ask how to integrate a new cipher into both libcrypto and libssl. While 
the process is still fresh in my head, I was wondering if the community would 
benefit in having some documentation on the process to follow and issues that 
may arise? Possibly add this into the OpenSSL wiki? I would love for this to be 
my first contribution to an open source project and help others who may find 
themselves in similar situations in the future.

Please let me know your thoughts.

Best,
Rob Schmicker
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Matthias Ballreich]

Hi there,


can anyone tell me how to parse a the Subject Directory Attribute Extension of 
a X509-Certificate in C++ with OpenSSL? I don't found any documentation or 
piece of code in the Github Repo of OpenSSL.


I read the Extension this way:

int loc = X509_get_ext_by_NID(cert, NID_subject_directory_attributes, -1);
X509_EXTENSION *ex = X509_get_ext(cert, loc);

But i stuck on how to continue and get the TypeValue-Stuff.
Would be very helpful if someone can help me.

thanks and best regards
Matthias

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

Re: [openssl-users] EVP_MD_CTX and EVP_PKEY_CTX? How to init? How to free?

[Blumenthal, Uri - 0553 - MITLL]

Understood. Thanks! 

Yes, it would be nice if 1_0_2-stable and 1_1 branches returned an error on an 
attempt to sign or verify with RSA_NO_PADDING.

Regards,
Uri

Sent from my iPhone

> On Apr 30, 2017, at 15:19, Dr. Stephen Henson  wrote:
> 
>> On Sun, Apr 30, 2017, Blumenthal, Uri - 0553 - MITLL wrote:
>> 
>> 
>> Semi-related question. Is RSA_NO_PADDING allowed for EVP signature? When I 
>> tried that (without using DigestSign of course), signing succeeded but 
>> verification always failed. Was that expected? Are there some special 
>> settings one needs to apply besides just setting the padding type?
>> 
> 
> With RSA_NO_PADDING it isn't possible to determine the length of the decrypted
> data during verify. We should really return an error code if an atttempt is
> made to use it for sign/verify.
> 
> 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


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EVP_MD_CTX and EVP_PKEY_CTX? How to init? How to free?

[Dr. Stephen Henson]

On Sun, Apr 30, 2017, Blumenthal, Uri - 0553 - MITLL wrote:

> 
> Semi-related question. Is RSA_NO_PADDING allowed for EVP signature? When I 
> tried that (without using DigestSign of course), signing succeeded but 
> verification always failed. Was that expected? Are there some special 
> settings one needs to apply besides just setting the padding type?
> 

With RSA_NO_PADDING it isn't possible to determine the length of the decrypted
data during verify. We should really return an error code if an atttempt is
made to use it for sign/verify.

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

Re: [openssl-users] Doubt regarding ExtendedMasterSecret

[Stiju Easo]

Hi ,

   I got the answer to this, and now the question looks bit stupid.
   Generation of master key is different in case of "Extended Master
Secret" ,

   I still have a doubt, what would be the contents in   SSL*
s->s3->handshake_buffer?
   I need to manually set this for my tool, i assume it holds both client
and server handshakes, am i right?


   if i am right , in openssl , i just need to populate
s3->handshake_buffer and set  flags to  s->session->flags &
SSL_SESS_FLAG_EXTMS.
   only unknown thing i have is  s3->handshake_buffer , what value to copy
there.


Regards
Stiju





On Fri, Apr 28, 2017 at 10:35 PM, Stiju Easo  wrote:

> Hi,
>
>
>I had a tool similar to SSLDump , which could decrypt SSL traffic (like
> Man in Middle).
>for this, I used to copy needed data to SSL* and used to call
> tls1_enc/ssl3_enc  to decrypt data.
>Everything used to work fine extended master secret came up in
> SSL header,
>even if it has empty value (just the place holder) as in pic attached.
> [image: Inline image 1]
>the SSL decryption failed, with -1 error from tls1_enc
> "-1: if the record's padding/AEAD-authenticator is invalid or, if
> sending,
>  an internal error occurred."
>on further debugging failure happens in EVP_Cipher().
>
>I tried OpenSSL1.1 and OpenSSL1.0.2, both has the same behavior.
>
>the doubt I have is
>1) if I have Extended Master Secret Extention type (with value 0)  in
> my data,  should I need to set something to SSL context so that.
>2) Is it necessary to use OpenSSL 1.1.0, if I don't intend to use value
> appearing in ExtendedMasterSecret?  I just want to ignore wat ever
> appearing in the header as of now. for this will 1.0.2 will do, given I
> resolve item (1)
>
>
> --
>
>
> Stiju Easo
>
>
>  The unexamined life is not worth living for man.
>   Socrates, in Plato, Dialogues, Apology
>   Greek philosopher in Athens (469 BC - 399 BC)
>
>


-- 


  Stiju Easo


 The unexamined life is not worth living for man.
  Socrates, in Plato, Dialogues, Apology
  Greek philosopher in Athens (469 BC - 399 BC)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

> On 20. Apr 2017, at 20:01, mahesh gs  wrote:
> 
> Hi,
> 
> This issue occur purely based on the time (sequence of events) at which SSL 
> read_state_machine enter the post processing of certificate verify which is 
> received from client.
> 
> Handshake works fine if the certificate verify post processing is done before 
> the next message arrives at SCTP socket layer (In your case may be there is a 
> delay in receiving the next message at SCTP layer). Handshake works fine even 
> in my environment some times. 
Can you try the attached patch and report if it fixes the issue for you?

Best regards
Michael



dtls.patch
Description: Binary data

> 
> 
> I added some debug statements, below is the debug statements. 
> 
> 
> Debug statements when the handshake does not work
> 
> 
> 
> Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  
> in - https://github.com/openssl/openssl/issues/3251
> 
> Debug logs when the handshake is successful
> 
> 
> 
> If no message is waiting to be received at socket layer then handshake is 
> successful. If message is waiting to be received at socket layer then the 
> handshake will never be completed. 
> 
> 
> Thanks,
> Mahesh G S
> 
> On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha  
> wrote:
> 
> 
> Matt Caswell wrote on 04/20/2017 03:23 PM:
> >
> >
> > On 20/04/17 14:19, Martin Brejcha wrote:
> >>
> >>
> >> Matt Caswell wrote on 04/20/2017 01:29 PM:
> >>>
> >>>
> >>> On 20/04/17 12:26, mahesh gs wrote:
>  Hi Matt,
> 
>  Yes I raised github case for the same issue. I also tried running this
>  call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
>  handshake is successful with the latest SNAPSHOT code which is not an
>  official release.
> 
>  I checked the github repo history and observer that during commits on
>  (11 th Jan) as a part of "Move state machine knowledge out of the record
>  layer".  "renegotiate" bit that is set to "2" in function
>  "tls_post_process_client_hello" has been removed. May be that is causing
>  the call flow to be successful in the latest SNAPSHOT release.
> 
>  I am assuming commits that are done on 11th Jan or later are not part of
>  release openssl 01.01.00e
> >>>
> >>> Ah. No. That commit is in the dev branch only (scheduled for version
> >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that
> >>> commit might help things, but probably a different solution is more
> >>> appropriate for 1.1.0.
> >>>
> >>> I'm looking at this issue at the moment.
> >>>
> >>> Matt
> >>>
> >>
> >> hi,
> >>
> >> btw: I've tested similar scenario and handshake works fine.
> >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, 
> >> non-blocking sockets and segmented certificate)
> >> So, it should work also with 1.1.0e version.
> >
> > Thanks. Did your handshake include client auth? I think this issue only
> > arises in that case.
> >
> > Matt
> >
> >
> 
> yes, client auth with segmented certificate has been included.
> 
> Martin
> 
> 
> 
> >
> >
> 
> --
> 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] Is there a "Golden" CA makefile?

[Jochen Bern]

On 04/29/2017 09:55 PM, John Lewis got digested:
> I am looking for a CA makefile to use with a openvpn tutorial I am
> writing https://github.com/Oflameo/openvpn_ws. Is there one officially
> endorsed by the openssl project?

Since you're specifically mentioning Open*VPN*, let me mention that
EasyRSA is a spin-off of that project. Not makefiles based, and working
with sub-CAs certainly isn't easy (though *possible* with version 3),
but if you want to see how the OpenVPN people think "their" CAs *should*
be run, that's what I'ld suggest to look at.

In a more general sense, the policies and technical limitations of CAs
vary too much for their operators to even agree on what color gold has,
I guess ...

(Not-quite-random example: Out of the box, OpenSSL dislikes CAs issuing
same-DN certs with overlapping validity periods. OpenVPN, again out of
the box, bases the mechanism of peer-specific configs on the CN. So if
you want to renew the cert of some device you're managing remotely
*through* the very VPN, you may(*) have an interest to *defeat* the
OpenSSL behavior, so as to issue the new cert before the old one expires
and saws off the branch you're adminning from.
(*) Of course, there *are* other techniques to work around the problem,
but.)

Regards,
-- 
Jochen Bern
Systemingenieur

Fon:+49 6151 9067-231
Fax:+49 6151 9067-290
E-Mail: jochen.b...@binect.de

www.binect.de
www.facebook.de/binect

Binect ist ausgezeichnet:
Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017

Binect GmbH

Robert-Koch-Straße 9, 64331 Weiterstadt, DE

Geschäftsführung: Christian Ladner, Dr. Frank Wermeyer, Nils Manegold
Unternehmenssitz: Weiterstadt
Register: Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
✁
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users