Talk:Libcrypto API - Revision history

Jflopezfernandez: Replying to thread

2019-07-29T03:27:49Z

Replying to thread

Matt at 09:38, 28 July 2019

2019-07-28T09:38:36Z

Matt: /* OPENSSL_config deprecated */

2019-07-28T09:35:57Z

OPENSSL_config deprecated

Jflopezfernandez: /* OPENSSL_config deprecated */ new section

2019-07-26T23:28:35Z

OPENSSL_config deprecated: new section

Jwalton: Fixed flow (I entered my comment between text body and Patrick's signature)

2013-03-07T04:37:35Z

Fixed flow (I entered my comment between text body and Patrick's signature)

Jwalton: /* Initialization, OPENSSL_conf and engines? */

2013-03-07T04:00:45Z

Initialization, OPENSSL_conf and engines?

Ppelleti: /* Return values */ agree with points about error handling

2013-03-06T01:25:56Z

Return values: agree with points about error handling

Matt: Further thoughts on return values

2013-03-05T22:31:27Z

Further thoughts on return values

Ppelleti: /* Return values */ spelling

2013-03-05T01:48:55Z

Return values: spelling

Ppelleti: /* Return values */

2013-03-05T00:37:54Z

Return values

← Older revision		Revision as of 03:27, 29 July 2019
Line 185:		Line 185:

	--[[User:Matt\|Matt]] ([[User talk:Matt\|talk]]) 09:38, 28 July 2019 (UTC)		--[[User:Matt\|Matt]] ([[User talk:Matt\|talk]]) 09:38, 28 July 2019 (UTC)
		+
		+	: Hey, thanks, Matt, that helped a lot; I was able to use that to grep right to the file where this is all defined. I'll post back here again once I'm confident I have some sample code that's both simple enough to be digestible as an introduction, but not so contrived it isn't useful.
		+
		+	: [[User:Jflopezfernandez\|Jflopezfernandez]] ([[User talk:Jflopezfernandez\|talk]]) 03:27, 29 July 2019 (UTC)

← Older revision		Revision as of 09:38, 28 July 2019
Line 183:		Line 183:

	This must be the first OpenSSL call you make (typically at the beginning of your application).		This must be the first OpenSSL call you make (typically at the beginning of your application).
		+
		+	--[[User:Matt\|Matt]] ([[User talk:Matt\|talk]]) 09:38, 28 July 2019 (UTC)

← Older revision		Revision as of 09:35, 28 July 2019
Line 177:		Line 177:

	[[User:Jflopezfernandez\|Jflopezfernandez]] ([[User talk:Jflopezfernandez\|talk]]) 23:28, 26 July 2019 (UTC)		[[User:Jflopezfernandez\|Jflopezfernandez]] ([[User talk:Jflopezfernandez\|talk]]) 23:28, 26 July 2019 (UTC)
		+
		+	The preferred approach to loading the default config file is:
		+
		+	OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL);
		+
		+	This must be the first OpenSSL call you make (typically at the beginning of your application).

← Older revision		Revision as of 23:28, 26 July 2019
Line 168:		Line 168:

	--[[User:Stevem\|Stevem]] 14:27, 4 March 2013 (UTC)		--[[User:Stevem\|Stevem]] 14:27, 4 March 2013 (UTC)
		+
		+	== OPENSSL_config deprecated ==
		+
		+	The sample code includes a call to <code>OPENSSL_config</code> which was deprecated in 1.1.0. I'm still familiarizing myself with the codebase and the documentation, and I therefore do not have a replacement suggestion yet, but if anyone is willing to impart their wisdom I'd be much obliged.
		+
		+	/* Load config file, and other important initialisation */
		+	OPENSSL_config(NULL);
		+
		+	[[User:Jflopezfernandez\|Jflopezfernandez]] ([[User talk:Jflopezfernandez\|talk]]) 23:28, 26 July 2019 (UTC)

@@ Line 65: / Line 65: @@
 So, to get RdRand support, you can either #define OPENSSL_LOAD_CONF when building your program, or you can call either ENGINE_load_builtin_engines() or OPENSSL_config() in your initialization sequence.  However, it appears that calling ENGINE_load_builtin_engines() more than once will leak memory, so ideally you don't want to call ENGINE_load_builtin_engines() if you also plan on calling OPENSSL_config(), or if you've defined OPENSSL_LOAD_CONF.  (Of course, since it's just a small fixed-size leak at initialization, this wouldn't really be a practical problem, but still makes me feel icky.)
 : > For AES-NI, it appears from the source code
@@ Line 73: / Line 75: @@
 : > different.
 : Perhaps it is because the hardware support for AES-NI and RDRAND was provided at different times. Its somewhat odd the Change Log shows them being cut-in at the same time in March, 2012 (http://www.openssl.org/news/changelog.html).
-: AES-NI and PCLMULQDQ was introduced with Sandy Bridge in January, 2011. Confer, http://en.wikipedia.org/wiki/Sandy_Bridge_(microarchitecture)
+: AES-NI and PCLMULQDQ was introduced with Sandy Bridge in January, 2011. Confer, http://en.wikipedia.org/wiki/Sandy_Bridge_(microarchitecture). RdRand was introduced with 3rd generation i5's and i7's via Ivy Bridge in April, 2012. Confer, http://en.wikipedia.org/wiki/Ivy_Bridge_(computer_processor).
 : [[User:Jwalton|Jwalton]] 04:00, 7 March 2013 (UTC)
 Note that the use of OPENSSL_config() '''is''' recommended during initialisation: this is mentioned in the manual page. Currently the routines associated with OPENSSL_config() can be used for adding OIDs and configuring ENGINEs. In future it may well do much more and calling OPENSSL_config() (or the actual conf library if finer control is needed) will automatically take advantage of that.

← Older revision		Revision as of 04:00, 7 March 2013
Line 65:		Line 65:

	So, to get RdRand support, you can either #define OPENSSL_LOAD_CONF when building your program, or you can call either ENGINE_load_builtin_engines() or OPENSSL_config() in your initialization sequence. However, it appears that calling ENGINE_load_builtin_engines() more than once will leak memory, so ideally you don't want to call ENGINE_load_builtin_engines() if you also plan on calling OPENSSL_config(), or if you've defined OPENSSL_LOAD_CONF. (Of course, since it's just a small fixed-size leak at initialization, this wouldn't really be a practical problem, but still makes me feel icky.)		So, to get RdRand support, you can either #define OPENSSL_LOAD_CONF when building your program, or you can call either ENGINE_load_builtin_engines() or OPENSSL_config() in your initialization sequence. However, it appears that calling ENGINE_load_builtin_engines() more than once will leak memory, so ideally you don't want to call ENGINE_load_builtin_engines() if you also plan on calling OPENSSL_config(), or if you've defined OPENSSL_LOAD_CONF. (Of course, since it's just a small fixed-size leak at initialization, this wouldn't really be a practical problem, but still makes me feel icky.)
		+
		+	: > For AES-NI, it appears from the source code
		+	: > (and was recently confirmed on the mailing list)
		+	: > that AES-NI is automatically used if it is
		+	: > available, without needing to do anything special.
		+	: > However, for RdRand, it appears that the answer is
		+	: > different.
		+	: Perhaps it is because the hardware support for AES-NI and RDRAND was provided at different times. Its somewhat odd the Change Log shows them being cut-in at the same time in March, 2012 (http://www.openssl.org/news/changelog.html).
		+	: AES-NI and PCLMULQDQ was introduced with Sandy Bridge in January, 2011. Confer, http://en.wikipedia.org/wiki/Sandy_Bridge_(microarchitecture)
		+	: RdRand was introduced with 3rd generation i5's and i7's via Ivy Bridge in April, 2012. Confer, http://en.wikipedia.org/wiki/Ivy_Bridge_(computer_processor).
		+	: [[User:Jwalton\|Jwalton]] 04:00, 7 March 2013 (UTC)

	--[[User:Ppelleti\|Ppelleti]] 04:33, 4 March 2013 (UTC)		--[[User:Ppelleti\|Ppelleti]] 04:33, 4 March 2013 (UTC)

@@ Line 112: / Line 112: @@
 </pre>
 --[[User:Matt|Matt]] 22:31, 5 March 2013 (UTC)
 ==Old Discussions==

← Older revision		Revision as of 22:31, 5 March 2013
Line 100:		Line 100:

	--[[User:Ppelleti\|Ppelleti]] 00:37, 5 March 2013 (UTC)		--[[User:Ppelleti\|Ppelleti]] 00:37, 5 March 2013 (UTC)
		+
		+	I'm happy with that...but now I'm wondering whether for consistency we should use this throughout the examples that we post on the wiki.
		+
		+	Also, the way the page now reads it looks like we are only recommending your idiom for those functions which might return something other than 0 or 1. Would it not be better to recommend this for all functions even if they do only return 0 or 1. By getting into the habit of always checking in this way it probably means you are less likely to inadvertently go wrong.
		+
		+	Finally, is it not the case that most of the time the if statement is checking of an error condition. Therefore shouldn't we write the code more like this:
		+
		+	<pre>
		+	if(1 != some_function())
		+	/* handle the error */
		+	</pre>
		+	--[[User:Matt\|Matt]] 22:31, 5 March 2013 (UTC)

	==Old Discussions==		==Old Discussions==

@@ Line 97: / Line 97: @@
 --[[User:Matt|Matt]] 21:05, 4 March 2013 (UTC)
-Yeah, I've noticed this, and in my own code I've chosen to always compare OpenSSL return values against 1 explicitly.  In the spirit of "be bold", I've gone ahead and added this as a recommendation on the page itself.  But if anyone things this is not a good approach, feel free to change it.
+Yeah, I've noticed this, and in my own code I've chosen to always compare OpenSSL return values against 1 explicitly.  In the spirit of "be bold", I've gone ahead and added this as a recommendation on the page itself.  But if anyone thinks this is not a good approach, feel free to change it.
 --[[User:Ppelleti|Ppelleti]] 00:37, 5 March 2013 (UTC)

← Older revision		Revision as of 00:37, 5 March 2013
Line 96:		Line 96:

	--[[User:Matt\|Matt]] 21:05, 4 March 2013 (UTC)		--[[User:Matt\|Matt]] 21:05, 4 March 2013 (UTC)
		+
		+	Yeah, I've noticed this, and in my own code I've chosen to always compare OpenSSL return values against 1 explicitly. In the spirit of "be bold", I've gone ahead and added this as a recommendation on the page itself. But if anyone things this is not a good approach, feel free to change it.
		+
		+	--[[User:Ppelleti\|Ppelleti]] 00:37, 5 March 2013 (UTC)

	==Old Discussions==		==Old Discussions==