Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Viktor Dukhovni]

On Thu, Apr 27, 2017 at 04:32:33PM +0100, Matt Caswell wrote:

> >>> Does openssl  provide any way to set MSG_NOSIGNAL on sendmsg (Underlying 
> >>> TCP/IP socket layer) ?
> >>
> >> No.  You will have to modify the code yourself.
> > 
> > Actually, it is possible to do the I/O in application code, using
> > any "write some data down a socket" API of the application's choice.
> 
> The OP is using SCTP (which uses DTLS). The above approach is
> problematic in DTLS. ...

Thanks, I missed the SCTP part of the requirements.

On Thu, Apr 27, 2017 at 04:26:22PM +0530, mahesh gs wrote:

> We are using Openssl for establish a secure communications for both
> TCP/SCTP connections.

The approach I suggested will only work for TLS with TCP.  For DTLS
with SCTP you'll need something else.  Does SCTP also raise SIGPIPE
on write() when the remote end is closed?

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Ryan Murray]

Great article. Who is the author?

Sent from Mail for Windows 10

From: Viktor Dukhovni
Sent: Thursday, April 27, 2017 11:54 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

On Thu, Apr 27, 2017 at 12:32:42PM +, Salz, Rich via openssl-users wrote:

> > Does openssl  provide any way to set MSG_NOSIGNAL on sendmsg (Underlying 
> > TCP/IP socket layer) ?
> 
> No.  You will have to modify the code yourself.

Actually, it is possible to do the I/O in application code, using
any "write some data down a socket" API of the application's choice.

https://www.openssl.org/docs/man1.0.2/crypto/BIO_s_bio.html

In particular, the OP could use sendmsg() to move data between the
SSL layer and the network.

For a complete example, see network_biopair_interop() function in
Postfix 2.3 (recent Postfix releases no longer use this approach).


https://github.com/vdukhovni/postfix/blob/postfix-2.3/postfix/src/tls/tls_bio_ops.c

-- 
Viktor.
-- 
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] Query regarding MSG_NOSIGNAL with SSL_Write

[Matt Caswell]

On 27/04/17 15:53, Viktor Dukhovni wrote:
> On Thu, Apr 27, 2017 at 12:32:42PM +, Salz, Rich via openssl-users wrote:
> 
>>> Does openssl  provide any way to set MSG_NOSIGNAL on sendmsg (Underlying 
>>> TCP/IP socket layer) ?
>>
>> No.  You will have to modify the code yourself.
> 
> Actually, it is possible to do the I/O in application code, using
> any "write some data down a socket" API of the application's choice.
> 
> https://www.openssl.org/docs/man1.0.2/crypto/BIO_s_bio.html
> 
> In particular, the OP could use sendmsg() to move data between the
> SSL layer and the network.
> 
> For a complete example, see network_biopair_interop() function in
> Postfix 2.3 (recent Postfix releases no longer use this approach).
> 
> 
> https://github.com/vdukhovni/postfix/blob/postfix-2.3/postfix/src/tls/tls_bio_ops.c
> 

The OP is using SCTP (which uses DTLS). The above approach is
problematic in DTLS. The DTLS code assumes that the BIO will provide a
set of datagram related ctrls (which are of course available if you use
a straight BIO_s_datagram()). BIO pairs don't support those ctrls.
Additionally they don't respect datagram boundaries.

You could use a custom filter BIO for a similar effect which can pass on
the ctrls down to the final source/sink BIO - and just use it to
intercept the "write" calls and plug in your own custom call of
sendmsg(). That would probably work with straight DTLS over UDP.

Unfortunately the libssl SCTP code is even more restrictive than normal
DTLS. It tests whether you are using SCTP by calling BIO_dgram_is_sctp()
on the read or write BIO:

int BIO_dgram_is_sctp(BIO *bio)
{
return (BIO_method_type(bio) == BIO_TYPE_DGRAM_SCTP);
}

If you plug in your own custom BIO it fails to detect SCTP :-(

The code also calls a number of other BIO specific functions such as
BIO_dgram_sctp_wait_for_dry() and BIO_dgram_sctp_msg_waiting().

In other words the libssl SCTP code is tightly coupled to the SCTP BIO
implementation - which effectively rules out custom BIOs.

The code could do with an overhaul, but not that many people use SCTP so
it hasn't really been a priority :-(

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Viktor Dukhovni]

On Thu, Apr 27, 2017 at 12:32:42PM +, Salz, Rich via openssl-users wrote:

> > Does openssl  provide any way to set MSG_NOSIGNAL on sendmsg (Underlying 
> > TCP/IP socket layer) ?
> 
> No.  You will have to modify the code yourself.

Actually, it is possible to do the I/O in application code, using
any "write some data down a socket" API of the application's choice.

https://www.openssl.org/docs/man1.0.2/crypto/BIO_s_bio.html

In particular, the OP could use sendmsg() to move data between the
SSL layer and the network.

For a complete example, see network_biopair_interop() function in
Postfix 2.3 (recent Postfix releases no longer use this approach).


https://github.com/vdukhovni/postfix/blob/postfix-2.3/postfix/src/tls/tls_bio_ops.c

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

Re: [openssl-users] How many SAN entries...?

[Blumenthal, Uri - 0553 - MITLL]

It depends on the CA in question, more so on the number of the attributes that 
are included, and of course on the set of users. ;-)

So far I assure you I've no concern for pitchforks. ;-)

Regards,
Uri

P.S. Why do you think validating, e.g., three email addresses is any more 
difficult than one? If that one is not under your direct control, that is? 
Sure, it may take longer to validate three - but it's the "process" time, not 
"human/employee" time. 

Sent from my iPhone

> On Apr 27, 2017, at 10:28, Jochen Bern  wrote:
> 
> On 04/27/2017 04:09 PM, openssl-users-requ...@openssl.org digested:
>> From: "Blumenthal, Uri - 0553 - MITLL" 
>> 
>> You do not "revoke" a subset of attributes aka SAN emails. When any of
>> the certified attributes changes (i.e., is certification no longer valid),
>> the certificate is revoked and (possibly) re-issued.
> 
> Precisely. Now imagine the cert being used for S/MIME (why would a cert
> list several e-mail addresses if it weren't somehow related to e-mails
> and the addressee's identity?) and the CA or its procedures insisting on
> renewing keypairs when a new cert is issued. I'ld say you'ld get users
> and their pitchforks asking for multiple SINGLE-attribute/value certs
> real fast.
> 
> 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.
> 
> -- 
> 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] How many SAN entries...?

[Jochen Bern]

On 04/27/2017 04:09 PM, openssl-users-requ...@openssl.org digested:
> From: "Blumenthal, Uri - 0553 - MITLL" 
> 
> You do not "revoke" a subset of attributes aka SAN emails. When any of
> the certified attributes changes (i.e., is certification no longer valid),
> the certificate is revoked and (possibly) re-issued.

Precisely. Now imagine the cert being used for S/MIME (why would a cert
list several e-mail addresses if it weren't somehow related to e-mails
and the addressee's identity?) and the CA or its procedures insisting on
renewing keypairs when a new cert is issued. I'ld say you'ld get users
and their pitchforks asking for multiple SINGLE-attribute/value certs
real fast.

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

Re: [openssl-users] How many SAN entries...?

[Blumenthal, Uri - 0553 - MITLL]

You do not "revoke" a subset of attributes aka SAN emails. When any of the 
certified attributes changes (i.e., is certification no longer valid), the 
certificate is revoked and (possibly) re-issued. The process is no different 
than with any other set of attributes, several of which may be owned/controlled 
by different organizations.

Regards,
Uri

Sent from my iPhone

> On Apr 27, 2017, at 09:41, Jochen Bern  wrote:
> 
> On 04/26/2017 07:13 PM, Viktor Dukhovni was digested as writing:
>> On Apr 26, 2017, at 1:03 PM, Blumenthal, Uri - 0553 - MITLL 
>>  wrote:
>>> It?s been my understanding that a cert can contain as many SAN attributes 
>>> as needed,
>>> but it appears that Apple believes it has to be only one (because 
>>> certificates with
>>> more than one are not processed properly).
>> 
>> Perhaps CAs have rarely issued email certificates with multiple email 
>> addresses. 
> 
> The mechanics of verifying - or, if necessary, revoking - every single
> one should be ... interesting. Unless, maybe, it's a boatload of
> ("typo"?) aliases from the same organization.
> 
> [Remembers manually splitting others' PGP pubkeys into single-user-ID
> ones after signing parties so as to send every freshly-signed ID only to
> the *one* address stated in it]
> 
> 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.
> 
> -- 
> 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] How many SAN entries...?

[Jochen Bern]

On 04/26/2017 07:13 PM, Viktor Dukhovni was digested as writing:
> On Apr 26, 2017, at 1:03 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
>> It?s been my understanding that a cert can contain as many SAN attributes as 
>> needed,
>> but it appears that Apple believes it has to be only one (because 
>> certificates with
>> more than one are not processed properly).
> 
> Perhaps CAs have rarely issued email certificates with multiple email 
> addresses. 

The mechanics of verifying - or, if necessary, revoking - every single
one should be ... interesting. Unless, maybe, it's a boatload of
("typo"?) aliases from the same organization.

[Remembers manually splitting others' PGP pubkeys into single-user-ID
ones after signing parties so as to send every freshly-signed ID only to
the *one* address stated in it]

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

Re: [openssl-users] AES-256 Do I need random IV?

[Yaşar Arabacı]

Hello Again,

Sorry, I should have explained myself better. I am using AES-256 in
CBC mode. I am getting a string as a password, and using
PKCS5_PBKDF2_HMAC_SHA1 function to generate 256 bit key and 128 bit
IV. I was wondering if generating and IV like this is necessary, or
can I just use a constant IV value with every encryption.


Here is my actual test code in C;

#define SZ_SALT 16 /* 128 bit salt */
#define NUM_ITER 1000

#define SZ_KEY 32 /* 256 bits */
#define SZ_IV 16 /* 128 bits */

#define SZ_GENERATED (SZ_KEY+SZ_IV)

/* +1 for null terminator */
unsigned char key[SZ_KEY+1];
unsigned char iv[SZ_IV + 1];

char *password = "ThisMyPass";
char *data = "This is important data to be encrypted";

unsigned char salt[SZ_SALT];
RAND_bytes(salt, SZ_SALT);

unsigned char generated[SZ_GENERATED];

if (PKCS5_PBKDF2_HMAC_SHA1(password, -1, salt, SZ_SALT, NUM_ITER,
SZ_GENERATED, [0]) == 0)
{
exit(1);
}

memcpy(key, generated, SZ_KEY);
key[SZ_KEY] == '\0';

memcpy(iv, (unsigned char *)generated + SZ_KEY, SZ_IV);
iv[SZ_IV] = '\0';


2017-04-27 15:34 GMT+03:00 Salz, Rich via openssl-users
:
>> For AES-256 encryption, should IV be random? I am already using a random
>> salt, so I was wondering if IV should be random too.
>
> It should be non-repeating.  It can just be a counter.
>
> (Yes, I know OP didn't ask about AESGCM.  But if they're coming here for 
> advice ... )
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



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

Re: [openssl-users] AES-256 Do I need random IV?

[Blumenthal, Uri - 0553 - MITLL]

Classic requirement is that IV is unique per key. 

As theoretical crypto evolved, and attacks like Chosen Ciphertext Attack (you 
can make the victim to encrypt any plaintext of your choice (aka CPA), *and* 
*decrypt* any ciphertext of your choice) were developed, CBC could not hold 
against such an attack. Here the recommendation to use not only unique but 
unpredictable (aka random) IV. 

So it boils down to your user case and that model: e.g., if it may be possible 
for an attacker to feed you ciphertext and learn the results of your decryption 
- your IV may need to be random.

Regards,
Uri

Sent from my iPhone

On Apr 27, 2017, at 08:34, Salz, Rich via openssl-users 
 wrote:

>> For AES-256 encryption, should IV be random? I am already using a random
>> salt, so I was wondering if IV should be random too.
> 
> It should be non-repeating.  It can just be a counter.
> 
> (Yes, I know OP didn't ask about AESGCM.  But if they're coming here for 
> advice ... )
> 
> -- 
> 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] AES-256 Do I need random IV?

[Salz, Rich via openssl-users]

> For AES-256 encryption, should IV be random? I am already using a random
> salt, so I was wondering if IV should be random too.

It should be non-repeating.  It can just be a counter.

(Yes, I know OP didn't ask about AESGCM.  But if they're coming here for advice 
... )

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Salz, Rich via openssl-users]

> Does openssl  provide any way to set MSG_NOSIGNAL on sendmsg (Underlying 
> TCP/IP socket layer) ?

No.  You will have to modify the code yourself.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] AES-256 Do I need random IV?

[Jakob Bohm]

On 27/04/2017 14:00, Yaşar Arabacı wrote:

Hi,

For AES-256 encryption, should IV be random? I am already using a
random salt, so I was wondering if IV should be random too.

Thanks in advance


AES itself takes neither an IV nor a salt.

AES in CBC mode takes a 128 bit IV for the CBC mode, it is best if
attackers cannot predict the IV before providing some data that they
"trick" you into encrypting.

AES in CBC mode should also not be used more than once with the same
combination of IV and key.

Various ways to choose a key (256 bit for AES-256) from a
human-memorable password involve the use of a salt to get different
keys for different runs with the same password, and to make the number
of possible keys much larger than the number of possible human-memorable
passwords.  Using a random or otherwise unpredictable key that isn't
from a password at all is usually safer than using a key based on a
password.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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

Re: [openssl-users] AES-256 Do I need random IV?

[Hanno Böck]

On Thu, 27 Apr 2017 15:00:37 +0300
Yaşar Arabacı  wrote:

> For AES-256 encryption, should IV be random? I am already using a
> random salt, so I was wondering if IV should be random too.

An IV is part of a cipher mode. AES-256 is just a block cipher. You
can't use it on its own. So you need to specify which cipher mode you
want to use in order to make sense. You most likely want to use GCM.

The requirement for the IV is usually that it's unique. Choosing it
at random may or may not be a good idea, depending on how much data
you encrypt and how long the IV is for that particular cipher mode. For
GCM using random IVs is not exactly recommended, better use a counter
if you can keep state. But if you only encrypt small amounts of data
per key a random IV is doable.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] AES-256 Do I need random IV?

[Yaşar Arabacı]

Hi,

For AES-256 encryption, should IV be random? I am already using a
random salt, so I was wondering if IV should be random too.

Thanks in advance

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Wouter Verhelst]

On 27-04-17 13:01, Wouter Verhelst wrote:
> On 27-04-17 12:56, mahesh gs wrote:
>> Hi,
>>
>> We are using Openssl for establish a secure communications for both
>> TCP/SCTP connections.
>>
>> In our application it is possible that remote end forcefully disconnect
>> the connection due to which 
>>
>> SSL_Write raises a SIGPIPE which we want to suppress. Does openssl 
>>
>> provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
>> layer) ?
>>
>> Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
>> not supported by LINUX 
> 
> You want to set the socket to nonblocking:
> 
> flags = fcntl(socket, F_GETFL, 0);
> flags |= O_NONBLOCK
> fcntl(socket, F_SETFL, flags);
> 
> (You'll need to add error checking for the fcntl() calls)

Actually, I confused two different issues here. Ignore me :-)

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Matt Caswell]

On 27/04/17 11:56, mahesh gs wrote:
> Hi,
> 
> We are using Openssl for establish a secure communications for both
> TCP/SCTP connections.
> 
> In our application it is possible that remote end forcefully disconnect
> the connection due to which 
> 
> SSL_Write raises a SIGPIPE which we want to suppress. Does openssl 
> 
> provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> layer) ?

No, there is no option to do that at the moment.

> 
> Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> not supported by LINUX 
> 
> and also we are unable to stop the SIGPIPE with function call
> signal(SIGPIPE, SIG_IGN).

Unable because you want SIGPIPE for other areas of your application? Or
for some other reason?

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Wouter Verhelst]

On 27-04-17 12:56, mahesh gs wrote:
> Hi,
> 
> We are using Openssl for establish a secure communications for both
> TCP/SCTP connections.
> 
> In our application it is possible that remote end forcefully disconnect
> the connection due to which 
> 
> SSL_Write raises a SIGPIPE which we want to suppress. Does openssl 
> 
> provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> layer) ?
> 
> Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> not supported by LINUX 

You want to set the socket to nonblocking:

flags = fcntl(socket, F_GETFL, 0);
flags |= O_NONBLOCK
fcntl(socket, F_SETFL, flags);

(You'll need to add error checking for the fcntl() calls)

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

[openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[mahesh gs]

Hi,

We are using Openssl for establish a secure communications for both
TCP/SCTP connections.

In our application it is possible that remote end forcefully disconnect the
connection due to which

SSL_Write raises a SIGPIPE which we want to suppress. Does openssl

provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
layer) ?

Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is not
supported by LINUX

and also we are unable to stop the SIGPIPE with function call
signal(SIGPIPE, SIG_IGN).


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