RE: Improving Developer Documentation
There is a vast quantity of OpenSSL information on the Internet. There's even an O'Reilly book: http://www.amazon.co.uk/Network-Security-OpenSSL-Cryptography-Communications/dp/059600270X This looks like a good one to start with: http://www.rtfm.com/openssl-examples/part1.pdf Whether they could all be better linked from the OpenSSL wiki is a different question of course :) Good luck! Message Received: Nov 14 2014, 01:58 AM From: Casey Dunham casey.dun...@gmail.com To: openssl-dev@openssl.org Cc: Subject: Improving Developer Documentation Greetings, I have just subscribed and hopefully I am not breaking any list etiquette here, but I wanted to respond to the thread that was started back in April on Improving the Documentation for OpenSSL. http://marc.info/?l=openssl-devm=139832883828644 I am a developer (BS CS, Minor in Math) but not up to speed with the OpenSSL library and more to my immediate interests, the cryptographic library that is part of OpenSSL. I am looking at using it in an upcoming project, but I definitely need to learn more about crypto. However, getting started with OpenSSL from reading the main project page at openssl.org and the wiki leaves a bit to be desired. The wiki was very useful however as it was the only place I could find usage examples ;) It took me a while to get started with a simple example and just getting an overview of the API is not easy (yes the source code which I am using). I also noticed that some of the code examples need to be updated. So I think that there are really three different areas of documentation that would be useful: - User documentation for the command line applications - Developer documentation for the OpenSSL / Crypto APIs - Up to date code examples for the usage of the APIs Having a single online resource for this would be great (unless I am completely missing a resource here). My main incentive is to provide a resource that developers could use to get started with the API quickly while also providing inline best practices and good coding examples. I have sent an email requesting access to the wiki and am interested in helping out where I can. Sorry for the long message! Regards, Casey __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Improving Developer Documentation
http://www.amazon.co.uk/Network-Security-OpenSSL-Cryptography-Communications/dp/059600270X I've found basics and even more advanced topics in this book, but please notice that it is more than 10 years old, so doesn't cover new stuff and I've found some information outdated. Still - good book. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Improving Developer Documentation
In looking for documentation regarding OpenSSL all I have found have been outdated examples. Even the rtfm link is unmaintained and has not been updated since 2002, according to this: http://www.rtfm.com/openssl-examples/ I think it would be great to link to these from a single source on the wiki. I am still going through the wiki and not sure if a page for this already exists. Perhaps I can make that a task to work on is getting all resources into a single place. C On Fri Nov 14 2014 at 9:05:46 AM Krzysztof Kwiatkowski krzys...@leeds.pl wrote: http://www.amazon.co.uk/Network-Security-OpenSSL- Cryptography-Communications/dp/059600270X I've found basics and even more advanced topics in this book, but please notice that it is more than 10 years old, so doesn't cover new stuff and I've found some information outdated. Still - good book.
RE: Improving Developer Documentation
I would applaud the effort to create better (and more tutorial-style) documentation. It would also be great to bring the documentation and examples up to date. [Description: cid:image001.jpg@01CFFF4A.CA221DD0] -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of david.ll...@fsmail.net Sent: Friday, November 14, 2014 8:03 AM To: openssl-dev@openssl.org; casey.dun...@gmail.com Subject: RE: Improving Developer Documentation There is a vast quantity of OpenSSL information on the Internet. There's even an O'Reilly book: http://www.amazon.co.uk/Network-Security-OpenSSL-Cryptography-Communications/dp/059600270X This looks like a good one to start with: http://www.rtfm.com/openssl-examples/part1.pdf Whether they could all be better linked from the OpenSSL wiki is a different question of course :) Good luck! Message Received: Nov 14 2014, 01:58 AM From: Casey Dunham casey.dun...@gmail.com To: openssl-dev@openssl.org Cc: Subject: Improving Developer Documentation Greetings, I have just subscribed and hopefully I am not breaking any list etiquette here, but I wanted to respond to the thread that was started back in April on Improving the Documentation for OpenSSL. http://marc.info/?l=openssl-devm=139832883828644 I am a developer (BS CS, Minor in Math) but not up to speed with the OpenSSL library and more to my immediate interests, the cryptographic library that is part of OpenSSL. I am looking at using it in an upcoming project, but I definitely need to learn more about crypto. However, getting started with OpenSSL from reading the main project page at openssl.org and the wiki leaves a bit to be desired. The wiki was very useful however as it was the only place I could find usage examples ;) It took me a while to get started with a simple example and just getting an overview of the API is not easy (yes the source code which I am using). I also noticed that some of the code examples need to be updated. So I think that there are really three different areas of documentation that would be useful: - User documentation for the command line applications - Developer documentation for the OpenSSL / Crypto APIs - Up to date code examples for the usage of the APIs Having a single online resource for this would be great (unless I am completely missing a resource here). My main incentive is to provide a resource that developers could use to get started with the API quickly while also providing inline best practices and good coding examples. I have sent an email requesting access to the wiki and am interested in helping out where I can. Sorry for the long message! Regards, Casey __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org attachment: Stephen F Bush.vcf
[PATCH] User can choose the public exponent in genrsa
The user can call RSA key generation and specify the public
exponent exp in a hexadecimal format.
Example: openssl genrsa -choose 72bdf -out key.pem 4096
Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com
---
apps/genrsa.c | 47 +++
crypto/objects/obj_xref.h | 2 +-
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/apps/genrsa.c b/apps/genrsa.c
index 6b835c0..fd4bb63 100644
--- a/apps/genrsa.c
+++ b/apps/genrsa.c
@@ -98,6 +98,7 @@ int MAIN(int argc, char **argv)
long l;
const EVP_CIPHER *enc=NULL;
unsigned long f4=RSA_F4;
+ char *exp = NULL;
char *outfile=NULL;
char *passargout = NULL, *passout = NULL;
#ifndef OPENSSL_NO_ENGINE
@@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
f4=3;
else if (strcmp(*argv,-F4) == 0 || strcmp(*argv,-f4) == 0)
f4=RSA_F4;
+ else if (strcmp(*argv,-choose) == 0)
+ {
+ if (--argc 1) goto bad;
+ exp = *(++argv);
+ /* Not checking whether exp = 2**16+1 since there is
+* no proof that small
+* public exponent is a threat.
+* Choosing e = 1 or e = 3 is thus possible
+*/
+ if(!BN_hex2bn(bn,exp)) goto err;
+ if(!BN_is_odd(bn))
+ {
+ BIO_printf(bio_err,Public exponent e has to be
odd\n);
+ goto err;
+ }
+ }
#ifndef OPENSSL_NO_ENGINE
else if (strcmp(*argv,-engine) == 0)
{
@@ -218,6 +235,7 @@ bad:
BIO_printf(bio_err, -passout argoutput file pass phrase
source\n);
BIO_printf(bio_err, -f4 use F4 (0x10001) for the E
value\n);
BIO_printf(bio_err, -3 use 3 for the E value\n);
+ BIO_printf(bio_err, -choose exp use exp hexadecimal string
as
public exponent\n);
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err, -engine e use engine e, possibly a
hardware device.\n);
#endif
@@ -273,29 +291,42 @@ bad:
#else
rsa = RSA_new_method(e);
#endif
+
if (!rsa)
goto err;
if (non_fips_allow)
rsa-flags |= RSA_FLAG_NON_FIPS_ALLOW;
- if(!BN_set_word(bn, f4) || !RSA_generate_key_ex(rsa, num, bn, cb))
+ if (exp != NULL)
+ {
+ if (!RSA_generate_key_ex(rsa, num, bn, cb))
+ goto err;
+ }
+ else if(!BN_set_word(bn, f4) || !RSA_generate_key_ex(rsa, num, bn, cb))
goto err;
-
+
app_RAND_write_file(NULL, bio_err);
/* We need to do the following for when the base number size is
* long, esp windows 3.1 . */
- l=0L;
- for (i=0; irsa-e-top; i++)
+ if (exp == NULL || strlen(exp) = 16)
{
+ l=0L;
+ for (i=0; irsa-e-top; i++)
+ {
#ifndef SIXTY_FOUR_BIT
- l=BN_BITS4;
- l=BN_BITS4;
+ l=BN_BITS4;
+ l=BN_BITS4;
#endif
- l+=rsa-e-d[i];
+ l+=rsa-e-d[i];
+ }
+ BIO_printf(bio_err,e is %ld (0x%lX)\n,l,l);
+ }
+ else if (exp != NULL)
+ {
+ BIO_printf(bio_err,e is 0x%s\n,exp);
}
- BIO_printf(bio_err,e is %ld (0x%lX)\n,l,l);
{
PW_CB_DATA cb_data;
cb_data.password = passout;
diff --git a/crypto/objects/obj_xref.h b/crypto/objects/obj_xref.h
index cfd628a..2b3dc6d 100644
--- a/crypto/objects/obj_xref.h
+++ b/crypto/objects/obj_xref.h
@@ -54,8 +54,8 @@ static const nid_triple sigoid_srt[] =
static const nid_triple * const sigoid_srt_xref[] =
{
sigoid_srt[29],
- sigoid_srt[17],
sigoid_srt[18],
+ sigoid_srt[17],
sigoid_srt[0],
sigoid_srt[1],
sigoid_srt[7],
--
2.1.0
Re: [PATCH] User can choose the public exponent in genrsa
On Fri, Nov 14, 2014 at 11:47:11AM -0600, Quentin Gouchet wrote:
@@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
f4=3;
else if (strcmp(*argv,-F4) == 0 || strcmp(*argv,-f4) == 0)
f4=RSA_F4;
+ else if (strcmp(*argv,-choose) == 0)
+ {
+ if (--argc 1) goto bad;
+ exp = *(++argv);
+ /* Not checking whether exp = 2**16+1 since there is
+ * no proof that small
+ * public exponent is a threat.
+ * Choosing e = 1 or e = 3 is thus possible
+ */
+ if(!BN_hex2bn(bn,exp)) goto err;
+ if(!BN_is_odd(bn))
+ {
+ BIO_printf(bio_err,Public exponent e has to be
odd\n);
+ goto err;
+ }
+ }
#ifndef OPENSSL_NO_ENGINE
else if (strcmp(*argv,-engine) == 0)
{
* The -choose option is too vague. Every option is a choice,
Better would be -public_exponent.
* Small public exponets ARE a threat, and in particular e=3
MUST be avoided. While e=5 or e=17 are somewhat less
risky, I'd steer clear of these also.
Fielded system with e set to something other than 3 or 65537
are rare. Are custom public exponents really a good idea? Seems
like unnecessary flexibility for the user to mess up. I'd bolt it
down at 65537 and remove all other options.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] User can choose the public exponent in genrsa
On 11/14/2014 07:47 AM, Quentin Gouchet wrote: The user can call RSA key generation and specify the public exponent exp in a hexadecimal format. Example: openssl genrsa -choose 72bdf -out key.pem 4096 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com This is an interesting proposal, but i don't think it's a good idea. + /* Not checking whether exp = 2**16+1 since there is + * no proof that small + * public exponent is a threat. + * Choosing e = 1 or e = 3 is thus possible + */ This strikes me as dangerously misguided. See section 4 of Twenty years of attacks on the RSA cryptosystem by Dan Boneh for a description of several attacks on low public exponents: https://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf And afaict, e = 1 is a complete disaster. There are also more mundane problems with this patch (note that resolving these easy problems doesn't fix the serious concerns described above). * if it's going to be done, the argument should be better than -choose -- something like -exponent would be clearer. * there is no patch to the genrsa manpage included * the value is interpreted as hexadecimal, even though other values passed by the user to genrsa (like the number of bits) is interpreted as decimal --dkg signature.asc Description: OpenPGP digital signature
Re: [PATCH] User can choose the public exponent in genrsa
Am Freitag, 14. November 2014, 08:08:00 schrieb Daniel Kahn Gillmor: Hi Daniel, On 11/14/2014 07:47 AM, Quentin Gouchet wrote: The user can call RSA key generation and specify the public exponent exp in a hexadecimal format. Example: openssl genrsa -choose 72bdf -out key.pem 4096 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com This is an interesting proposal, but i don't think it's a good idea. I agree allowing to choose an arbitrary e is not so good. However, what kind of threats do you see when we would: - use 2**16+1 per default - allow 17 (-F4) as a legacy - allow arbitrary e as long as they are odd and larger than 2**16-1 - disallow anything else. I see that this patch does not enforce such restrictions. I suggest to update the patch to cover the mentioned restrictions. This should be harmless and give a user more flexibility without giving him a gun to shoot himself. -- Ciao Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: gmp engine
Dear Geoff, $ ./config enable-gmp -Iincludepath -Llibpath -lgmp Not with the quotes, right? It works for me without them, I didn't try with them. I confirm it works. Sorry for the noise, Paul Zimmermann __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] User can choose the public exponent in genrsa
Hi,
Am 14.11.2014 um 19:07 schrieb Viktor Dukhovni:
On Fri, Nov 14, 2014 at 11:47:11AM -0600, Quentin Gouchet wrote:
@@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
f4=3;
else if (strcmp(*argv,-F4) == 0 || strcmp(*argv,-f4) == 0)
f4=RSA_F4;
+else if (strcmp(*argv,-choose) == 0)
+{
+if (--argc 1) goto bad;
+exp = *(++argv);
+/* Not checking whether exp = 2**16+1 since there is
+ * no proof that small
+ * public exponent is a threat.
+ * Choosing e = 1 or e = 3 is thus possible
+ */
+if(!BN_hex2bn(bn,exp)) goto err;
+if(!BN_is_odd(bn))
+{
+BIO_printf(bio_err,Public exponent e has to be
odd\n);
+goto err;
+}
+}
#ifndef OPENSSL_NO_ENGINE
else if (strcmp(*argv,-engine) == 0)
{
* The -choose option is too vague. Every option is a choice,
Better would be -public_exponent.
* Small public exponets ARE a threat, and in particular e=3
MUST be avoided. While e=5 or e=17 are somewhat less
risky, I'd steer clear of these also.
Fielded system with e set to something other than 3 or 65537
are rare. Are custom public exponents really a good idea? Seems
like unnecessary flexibility for the user to mess up. I'd bolt it
down at 65537 and remove all other options.
Please don't bolt down at a fixed value, but instead only check sanity
of the choosen values. I use non-standard value for e in several places
and bolting things down on one value will cause trouble should we
someday discover that even 65537 is a bad choice, but an even bigger
exponent needs to be used instead.
Already now we have a problem with being limited to about 192 bit
effective security due to arbitrary limitations in the code[1]. As
explained there when using client certificates you are bound to 128 bit
as your certificate (if not ECC) becomes the limiting factor. Overcoming
those limits is hard enough as it stands. Let alone that the library
claims to be written without artificial restrictions.
Using non-standard exponents should be hard (and AFAIK there is a way
currently implemented already, it's just hardly documented anywhere),
such that you cannot plausibly deny you didn't know what you were doing,
but the library shouldn't throw rocks in your way either when you do.
Thus I'd prefer to skip this patch (for the reasons mentioned already by
others) and either do no change OR just add proper validations for the
exponent chosen by the user.
Kind regards,
BenBE.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] User can choose the public exponent in genrsa
Hi Ben,
I will add the proper validation for the exponent to be chosen by the user
then, taking in account everybody's comments.
Best,
Quentin
Quentin Gouchet
-
Mobile: +46(0)723-843256
2014-11-14 14:10 GMT-06:00 Benny Baumann be...@geshi.org:
Hi,
Am 14.11.2014 um 19:07 schrieb Viktor Dukhovni:
On Fri, Nov 14, 2014 at 11:47:11AM -0600, Quentin Gouchet wrote:
@@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
f4=3;
else if (strcmp(*argv,-F4) == 0 || strcmp(*argv,-f4)
== 0)
f4=RSA_F4;
+else if (strcmp(*argv,-choose) == 0)
+{
+if (--argc 1) goto bad;
+exp = *(++argv);
+/* Not checking whether exp = 2**16+1 since there
is
+ * no proof that small
+ * public exponent is a threat.
+ * Choosing e = 1 or e = 3 is thus possible
+ */
+if(!BN_hex2bn(bn,exp)) goto err;
+if(!BN_is_odd(bn))
+{
+BIO_printf(bio_err,Public exponent e has
to be odd\n);
+goto err;
+}
+}
#ifndef OPENSSL_NO_ENGINE
else if (strcmp(*argv,-engine) == 0)
{
* The -choose option is too vague. Every option is a choice,
Better would be -public_exponent.
* Small public exponets ARE a threat, and in particular e=3
MUST be avoided. While e=5 or e=17 are somewhat less
risky, I'd steer clear of these also.
Fielded system with e set to something other than 3 or 65537
are rare. Are custom public exponents really a good idea? Seems
like unnecessary flexibility for the user to mess up. I'd bolt it
down at 65537 and remove all other options.
Please don't bolt down at a fixed value, but instead only check sanity
of the choosen values. I use non-standard value for e in several places
and bolting things down on one value will cause trouble should we
someday discover that even 65537 is a bad choice, but an even bigger
exponent needs to be used instead.
Already now we have a problem with being limited to about 192 bit
effective security due to arbitrary limitations in the code[1]. As
explained there when using client certificates you are bound to 128 bit
as your certificate (if not ECC) becomes the limiting factor. Overcoming
those limits is hard enough as it stands. Let alone that the library
claims to be written without artificial restrictions.
Using non-standard exponents should be hard (and AFAIK there is a way
currently implemented already, it's just hardly documented anywhere),
such that you cannot plausibly deny you didn't know what you were doing,
but the library shouldn't throw rocks in your way either when you do.
Thus I'd prefer to skip this patch (for the reasons mentioned already by
others) and either do no change OR just add proper validations for the
exponent chosen by the user.
Kind regards,
BenBE.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453
Re: Improving Developer Documentation
OpenSSL APIs haven't changed much in 10 years :) In looking for documentation regarding OpenSSL all I have found have been outdated examples. Even the rtfm link is unmaintained and has not been updated since 2002, according to this: http://www.rtfm.com/openssl-examples/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Query regarding SSLv23 methods
On Fri, Nov 14, 2014 at 06:35:51AM +, Viktor Dukhovni wrote: On Fri, Nov 14, 2014 at 06:26:24AM +, Vaghasiya, Nimesh wrote: [ It is rude to ask user questions on the dev list (moved to Bcc). ] We are in process of disabling SSLv3 and SSLv2 protocols from all of our FreeBSD based applications. For SSLv23 methods we are setting SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 options as shown below, conn-ssl_ctx = SSL_CTX_new(SSLv23_server_method()); SSL_CTX_set_mode(conn-ssl_ctx, SSL_OP_NO_SSLv2); SSL_CTX_set_mode(conn-ssl_ctx, SSL_OP_NO_SSLv3); Does this ensure my SSLv23 methods will no more accept SSLv3 and SSLv2 connections ? No, it does not. You really should read the manpage for SSL_CTX_set_mode(3) that function is unrelated to setting the options in question. To control protocol feature and work-around options see SSL_CTX_set_options(3). So setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 should do what he wants to do, he's just using the wrong function to set the options. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2665] s_client support for starttls ldap
--On November 14, 2014 at 1:30:10 AM + Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Nov 13, 2014 at 04:57:25PM -0800, Quanah Gibson-Mount wrote: It would be cool to have the Net::SSLeay code as well, however, for other tests I'd like to set up. Attached. You'll need a sufficiently recent Net::SSLeay, build from CPAN if the packaged one is too old on your system. Thanks! I pulled in the patch that has OpenLDAP log the protocol cipher on the server side, so having the client side info will fill out the rest of what I need. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Improving Developer Documentation
Pre-Shared Keys might be one example of something that is hard to find in any documented example. Steve -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of david.ll...@fsmail.net Sent: Friday, November 14, 2014 4:16 PM To: openssl-dev@openssl.org; Krzysztof Kwiatkowski; openssl-dev@openssl.org Cc: owner-openssl-...@openssl.org Subject: Re: Improving Developer Documentation OpenSSL APIs haven't changed much in 10 years :) In looking for documentation regarding OpenSSL all I have found have been outdated examples. Even the rtfm link is unmaintained and has not been updated since 2002, according to this: http://www.rtfm.com/openssl-examples/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Improving Developer Documentation
SRP is another
On Fri, 2014-11-14 at 22:42 +, Bush, Stephen F (GE Global Research)
wrote:
Pre-Shared Keys might be one example of something that is hard to find in any
documented example.
Steve
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of david.ll...@fsmail.net
Sent: Friday, November 14, 2014 4:16 PM
To: openssl-dev@openssl.org; Krzysztof Kwiatkowski; openssl-dev@openssl.org
Cc: owner-openssl-...@openssl.org
Subject: Re: Improving Developer Documentation
OpenSSL APIs haven't changed much in 10 years :)
In looking for documentation regarding OpenSSL all I have found have
been outdated examples. Even the rtfm link is unmaintained and has not
been updated since 2002, according to this:
http://www.rtfm.com/openssl-examples/
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Ensڶj!(7yy'
yǢ_yl܅-ze5]}yo'ǫ[zzvǮ+aI/Mxn7ӝ4A'hh'睲CzXzjׅ-x6^6ۍ4D^qyiV-Y^y'ze+aƧD)קhfj!('u^+M4$;1+'睲E-x6^6ۍ4Eҥ$z^Ȩ*Z,j}Mt}zxh5睲wUҥz]*Z+Z
(6ַ*tt-
+J0H%ylPޮ^%uZ+'z)z{,ׯhn7)
ޖ^:gbtNbp
z{Kjx.jD1!ڰmiW1$Pj+Ɗ)ڶ)ݵ_w
z{Sʗ{VZǭ_*'Nw(v)m0E^Ȩ](~bz{ޝ+rzx6Mt}~MM4G^~)*'
uם5Mx]yMx]x]5('j۫z4\h{Rz֢')jjh'2ןjm+x
,rK.(4(4iۥ(4nd+x
,)jf-Jj'iqƧr
^x^4n4Myبj)]uM{AɔMɕ-́ЁᅵͽѡѡЁ́ɐѼ䁑յѕᅵ4(4)Mѕٔ4(4(=ɥ5ͅ4)ɽ聽ݹȵͰͰɜmѼݹȵͰͰɝt=
=٥͵4)Mɥ䰁9ٕȀаЀA44)Q聽ͰͰɜ-ѽ-ݥѭͭ쁽ͰͰɜ4)
聽ݹȵͰͰɜ4)MՉI%ɽ٥ٕȁյхѥ4(4(4(4)=MM0A%ٕ́ЁՍ啅̀4(4(4(%ȁյхѥɕɑ=MM0$ٔչٔ4(ёѕᅵ̸ٕѡљ́չх́Ѐ4(ѕͥȰɑѼѡ4(輽ܹљͰᅵ̼4(4)}|4)=MM0AɽЀ輽ܹͰɜ4)ٕЁ51ЀͰͰɜ4)ѽѕ1Ё5ȀɑͰɜ4(
RE: Improving Developer Documentation
Quantum key distribution systems are growing and it would be good to use PSK or
other mechanisms to help accommodate QKD symmetric keys.
Steve
-Original Message-
From: Krzysztof Kwiatkowski [mailto:krzys...@leeds.pl]
Sent: Friday, November 14, 2014 7:00 PM
To: Bush, Stephen F (GE Global Research)
Cc: openssl-dev@openssl.org; owner-openssl-...@openssl.org
Subject: Re: Improving Developer Documentation
SRP is another
On Fri, 2014-11-14 at 22:42 +, Bush, Stephen F (GE Global Research)
wrote:
Pre-Shared Keys might be one example of something that is hard to find in any
documented example.
Steve
-Original Message-
From: owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] On Behalf Of
david.ll...@fsmail.net
Sent: Friday, November 14, 2014 4:16 PM
To: openssl-dev@openssl.org; Krzysztof Kwiatkowski;
openssl-dev@openssl.org
Cc: owner-openssl-...@openssl.org
Subject: Re: Improving Developer Documentation
OpenSSL APIs haven't changed much in 10 years :)
In looking for documentation regarding OpenSSL all I have found have
been outdated examples. Even the rtfm link is unmaintained and has
not been updated since 2002, according to this:
http://www.rtfm.com/openssl-examples/
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Ensڶj!(7yy'
yǢ_yl܅-ze5]}yo'ǫ[zzvǮ+aI/Mxn7ӝ4A'hh'睲CzXzjׅ-x6^6ۍ4D^qyiV-Y^y'ze+aƧD)קhfj!('u^+M4$;1+'睲E-x6^6ۍ4Eҥ$z^Ȩ*Z,j}Mt}zxh5睲wUҥz]*Z+Z
(6ַ*tt-
+J0H%ylPޮ^%uZ+'z)z{,ׯhn7)
ޖ^:gbtNbp
z{Kjx.jD1!ڰmiW1$Pj+Ɗ)ڶ)ݵ_w
z{Sʗ{VZǭ_*'Nw(v)m0E^Ȩ](~bz{ޝ+rzx6Mt}~MM4G^~)*'
uם5Mx]yMx]x]5('j۫z4\h{Rz֢')jjh'2ןjm+x
,rK.(4(4iۥ(4nd+x
,)jf-Jj'iqƧr
^x^4n4Myبj)]uM{AɔMɕ-́ЁᅵͽѡѡЁ́ɐѼ䁑յѕᅵ4(4)Mѕٔ4(4(=ɥ5ͅ4)ɽ聽ݹȵͰͰɜmѼݹȵͰͰɝt=
=٥͵4)Mɥ䰁9ٕȀаЀA44)Q聽ͰͰɜ-ѽ-ݥѭͭ쁽ͰͰɜ4)
聽ݹȵͰͰɜ4)MՉI%ɽ٥ٕȁյхѥ4(4(4(4)=MM0A%ٕ́ЁՍ啅̀4(4(4(%ȁյхѥɕɑ=MM0$ٔչٔ4(ёѕᅵ̸ٕѡљ́
չх́Ѐ4(ѕͥȰɑѼѡ4(輽ܹљͰᅵ̼4(4)}}
}}}|4)=MM0AɽЀ輽ܹͰɜ4)ٕЁ51ЀͰͰɜ4)ѽѕ1Ё5ȀɑͰɜ4(
attachment: Stephen F Bush.vcf
Re: Improving Developer Documentation
If anyone wants to post some code, I'll start working to get it on the
wiki. Probably won't have time until Sunday, but those of you who are
posting this definitely know more about it than I do, so I think its safe
to assume we can start with your code and go from there!
C
On Fri Nov 14 2014 at 8:37:15 PM Bush, Stephen F (GE Global Research)
bus...@research.ge.com wrote:
Quantum key distribution systems are growing and it would be good to use
PSK or other mechanisms to help accommodate QKD symmetric keys.
Steve
-Original Message-
From: Krzysztof Kwiatkowski [mailto:krzys...@leeds.pl]
Sent: Friday, November 14, 2014 7:00 PM
To: Bush, Stephen F (GE Global Research)
Cc: openssl-dev@openssl.org; owner-openssl-...@openssl.org
Subject: Re: Improving Developer Documentation
SRP is another
On Fri, 2014-11-14 at 22:42 +, Bush, Stephen F (GE Global Research)
wrote:
Pre-Shared Keys might be one example of something that is hard to find
in any documented example.
Steve
-Original Message-
From: owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] On Behalf Of
david.ll...@fsmail.net
Sent: Friday, November 14, 2014 4:16 PM
To: openssl-dev@openssl.org; Krzysztof Kwiatkowski;
openssl-dev@openssl.org
Cc: owner-openssl-...@openssl.org
Subject: Re: Improving Developer Documentation
OpenSSL APIs haven't changed much in 10 years :)
In looking for documentation regarding OpenSSL all I have found have
been outdated examples. Even the rtfm link is unmaintained and has
not been updated since 2002, according to this:
http://www.rtfm.com/openssl-examples/
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Ensڶj!(7yy' yǢ_yl܅-ze5]}yo'ǫ[zzvǮ+aI/Mxn7ӝ4A'hh'睲CzXzjׅ-x6^6ۍ4D^
qyiV-Y^y'ze+aƧD)קhfj!('u^+M4$;1+'睲E-x6^6ۍ4Eҥ$z^Ȩ*Z,j}Mt}zxh5睲wUҥz]*Z+Z
(6ַ*tt-
+J0H%ylPޮ^%uZ+'z)z{,ׯhn7)
ޖ^:gbtNbp
z{Kjx.jD1!ڰmiW1$Pj+Ɗ)ڶ)ݵ_w
z{Sʗ{ VZǭ_*'Nw(v)m0E^Ȩ](~bz{ޝ+rzx6Mt}~MM4G^~)*'
uם5Mx]yMx]x]5('j۫z4\h{Rz֢')jjh'2ןjm+x
,rK.(4(4iۥ(4nd+x
,)jf-Jj'iqƧr
^x^4n4Myبj)]uM{AɔMɕ-́ЁᅵͽѡѡЁ́ɐѼ䁑յѕᅵ4(4)Mѕٔ4(4(=ɥ5ͅ4)ɽ聽ݹȵͰͰɜmѼݹȵͰͰɝt=
=٥͵4)Mɥ䰁9ٕȀаЀA44)Q聽ͰͰɜ-ѽ-ݥѭͭ쁽ͰͰɜ4)
聽ݹȵͰͰɜ4)MՉI%ɽ٥ٕȁյхѥ4(4(4(4)=MM0A%ٕ́ЁՍ啅̀4(4(4(%ȁյхѥɕɑ=MM0$ٔչٔ4(ёѕᅵ̸ٕѡљ́
չх́Ѐ4(ѕͥȰɑѼѡ4(輽ܹљͰᅵ̼4(4)}}
}}}|4)=MM0AɽЀ輽ܹͰɜ4)ٕЁ51ЀͰͰɜ4)ѽѕ1Ё5ȀɑͰɜ4(
