Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 5/13/2015 3:17 PM, Nico Williams wrote: > Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS > mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? Nico, Look for draft-burdis-cat-srp-sasl. It was never standardized but I believe there is an implementation in Cyrus/SASL. This is the most recent version I could find http://www.opensource.apple.com/source/passwordserver_sasl/passwordserver_sasl-159/cyrus_sasl/doc/draft-burdis-cat-srp-sasl-xx.txt Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
I wonder if we could do this in the KITTEN WG list. Maybe not every extension to TLS needs to be treated as a TLS WG work item... We should ask the security ADs. Nico -- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
We're closer. On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote: > On 13/05/2015 17:46, Nico Williams wrote: > >On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: > >>On 12/05/2015 21:45, Nico Williams wrote: > >>>On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: > How about the following simplifications for the new > extension, lets call it "GSS-2" (at least in this e-mail). > > 1. GSS (including SASL/GS2) is always done via the SPNego > GSS mechanism, which provides standard handling of > mechanism negotiation (including round-trip optimizations), > and is already its own standard (complete with workarounds > for historic bugs in the dominant implementation...). > >>> > >>>SASL/GS2 and SPNEGO are incompatible. > >> > >>How? I thought SPNEGO encapsulated and negotiated > >>arbitrary GSS mechanisms. > > > >The problem is that negotiating twice is bad (for various reasons), and > >SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is > >a two-level negotiation that is fraught with peril, therefore forbidden. > > Ok, having not studied the standard SASL in GSS > specification, I presumed each GSS-encapsulated SASL > mechanism would have its own GSS mechanism OID in > some systematic way, leaving just one negotiation. SASL/GS2 is the other way around: GSS in SASL. The idea is that you can have GSS as SASL mechanisms in a way that sucks less than the original GSS-in-SASL bridge in RFC (that added an extra round-trip), and which makes it easy to add mechanisms like SCRAM as both, a GSS and a SASL mechanism. I'm perfectly happy to drop SASL though. > >>To me the key benefit of SPNEGO is the existence of > >>already battle tested negotiation code readily available > >>i many/most current GSS implementation. It is one less > >>thing to design and implement wrong. > > > >It's quite complex owing to having been underspecified in the first > >place then having grown a number of bug workarounds over the years. > > Yes, but it is now a mature protocol, and I was trying > to avoid creating yet another near identical > handshake protocol. The only complication in a negotiation mechanism is protecting the negotiation. Since the TLS handshakes are ultimately integrity- protected, there's no complication at all to having the client send a list of mechanisms and the server pick one (the client can even send an optimistic choice's initial context token). In fact, it's much nicer than SPNEGO in many ways; if at all possible one should avoid SPNEGO. Among other things, not using SPNEGO means that it will be much easier to implement this protocol without extensions to GSS (extensions would be needed only to optimize it). > >In your protocol the client already sent a SPNEGO initial security > >context token. A response is required, as GSS context establishment > >token exchanges are strictly synchronous. > > As written, I had forgotten about the "Finished" > messages. Thus the point wasto simply delay the > server GSS response (2. GSS leg) to just after > switching onthe encryption, later in the same > round of messages. The 3. leg (second client to > server "GSS token") would then follow etc. We could extend GSS (see below) to support late channel binding, but since a mechanism might not be able to do it, this protocol would have to fall back on MIC tokens to complete the channel binding, in some cases at a cost of one more round trip. > >With PROT_READY there should be no need for an extra round-trip. > > Depends a lot on the mechanism. Some GSS mechanisms > (other than Kerberos IV/V) cannot use their MIC until > they have received a later token from the other end, > but can incorporate binding data earlier than that. I > think GSS-SRP-6a has that property. Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? > 6. If the GSS mechanism preferred by the client requires the > authenticated hash value to be known before sending the > first GSS leg, then the client shall simply abstain from > including that first leg in the first leg SPNego message > if sent in the client hello extension. > >>>If we're doing a MIC exchange then we don't need to know the channel > >>>binding a initial security context token production time. > >>However the early channel binding might save a leg. > > > >You mean late. Your idea seems to be to exposed knowledge of when is > >the latest that a mechanism can begin to use the channel binding so as > >to delay giving it the channel binding until we know it. That would be > >a significant change to GSS, and often it won't help (e.g., Kerberos, > >the mechanism of interest in this thread). > > The idea would be if an implementation (not the protocol > extension specification as such) is blessed with a > non-standard GSS option to provide the channel binding > after the 1. leg, but not wit
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
For the TL;DR: My original quick writeup included some mistakes in the details of TLS (forgot about Finished messages) and SASL/GS2. It is thus in more than anticipated need of change before it can become a proper spec, finding and fixing such mistakes is the main benefit of having this kind of discussion. On 13/05/2015 17:46, Nico Williams wrote: On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it "GSS-2" (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. Ok, having not studied the standard SASL in GSS specification, I presumed each GSS-encapsulated SASL mechanism would have its own GSS mechanism OID in some systematic way, leaving just one negotiation. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. Yes, but it is now a mature protocol, and I was trying to avoid creating yet another near identical handshake protocol. It'd be much easier to send a list of mechanism OIDs in the ClientHello, have the server announce a choice in its response, and have the first GSS token sent as early application data in the same flight as the client's Finished message (assuming traditional TLS handshakes here), with GSS channel binding. When the client knows what mechanism they want they could send the initial context token in the ClientHello (if it's not too large) and use MIC tokens for channel binding. But isn't that (essentially) what SPnego does, but in a standardized way with historic quirks? The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. However I strongly suspect that using ALPN will cause practical conflicts with early HTTP/2 implementations and early ALPN implementations, as such early implementations are likely to only cater to that single use of ALPN. Perhaps so. I would prefer to optimize the GSS flights as well too. Ditto. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension "GSS-2" to confirm support. Well, presumably the first response GSS token should go here. No, see below. In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. As written, I had forgotten about the "Finished" messages. Thus the point wasto simply delay the server GSS response (2. GSS leg) to just after switching onthe encryption, later in the same round of messages. The 3. leg (second client to server "GSS token") would then follow etc. The ordering of GSS message tokens is of cause crucial for the security guarantees of many mechanisms. It was all about when to send the next token, never about reordering or omitting them. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. Yep, however as this entails extra round trips, it is not the only option. With PROT_READY there should be no need for an extra round-trip. Depends a lot on the mechanism. Some GSS mechanisms (other than Kerberos IV/V) cannot use their MIC until they have received a later token from the other end, but can incorporate binding data earlier than that. I think GSS-SRP-6a has that property. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context t
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: > On 12/05/2015 21:45, Nico Williams wrote: > >On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: > >>How about the following simplifications for the new > >>extension, lets call it "GSS-2" (at least in this e-mail). > >> > >>1. GSS (including SASL/GS2) is always done via the SPNego > >>GSS mechanism, which provides standard handling of > >>mechanism negotiation (including round-trip optimizations), > >>and is already its own standard (complete with workarounds > >>for historic bugs in the dominant implementation...). > >SASL/GS2 and SPNEGO are incompatible. > > How? I thought SPNEGO encapsulated and negotiated > arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. > To me the key benefit of SPNEGO is the existence of > already battle tested negotiation code readily available > i many/most current GSS implementation. It is one less > thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. It'd be much easier to send a list of mechanism OIDs in the ClientHello, have the server announce a choice in its response, and have the first GSS token sent as early application data in the same flight as the client's Finished message (assuming traditional TLS handshakes here), with GSS channel binding. When the client knows what mechanism they want they could send the initial context token in the ClientHello (if it's not too large) and use MIC tokens for channel binding. > >The ALPN approach is to do the mechanism negotiation via ALPN. This is > >much better than SPNEGO in general. > > However I strongly suspect that using ALPN will cause > practical conflicts with early HTTP/2 implementations > and early ALPN implementations, as such early > implementations are likely to only cater to that > single use of ALPN. Perhaps so. I would prefer to optimize the GSS flights as well too. > >>3. The TLS server (if it supports and allows the extension) > >>responds with a 0 byte TLS extension "GSS-2" to confirm > >>support. > >Well, presumably the first response GSS token should go here. > No, see below. In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. > >>5. In the last legs, the GSS mechanism is told to (mutually > >>if possible) authenticate some already defined hash of the > >>TLS handshake, thereby protecting the key exchange.Other > >>than the round trip saving for the first 2 legs, this is > >>what distinguishes GSS-2 from simply doing application level > >>GSS over a TLS connection. Any GSS negotiated keys are not > >>used beyond this authentication of the TLS key exchange. > > > >This is the MIC exchange I mention above. > > Yep, however as this entails extra round trips, it is > not the only option. With PROT_READY there should be no need for an extra round-trip. > >>6. If the GSS mechanism preferred by the client requires the > >>authenticated hash value to be known before sending the > >>first GSS leg, then the client shall simply abstain from > >>including that first leg in the first leg SPNego message > >>if sent in the client hello extension. > > > >If we're doing a MIC exchange then we don't need to know the channel > >binding a initial security context token production time. > > However the early channel binding might save a leg. You mean late. Your idea seems to be to exposed knowledge of when is the latest that a mechanism can begin to use the channel binding so as to delay giving it the channel binding until we know it. That would be a significant change to GSS, and often it won't help (e.g., Kerberos, the mechanism of interest in this thread). > >>7. If the client wants encryption of the first GSS leg, it > >>can either abstain from including that leg in the first > >>SPNego GSS leg, or it can send a 0-byte first leg and then > >>send the real first SPNego leg in the first encrypted client > >>o server record, with the server responding with the second > >>leg in the first encrypted server to client record as before > >>(but no longer in the same round trip as the second half of > >>the TLS handshake). > > > >With the ALPN approach this is a given. > > However if the first leg need not be encrypted and > need not know thechannel binding, it can be sent a > round earlier. This can (I hope) be decided on a per > mechanism basis, thus if a GSS mechanism need not know > its channel binding until the second leg, > implementations that can provide the binding to the > GSS layer later can take advantage of it. No, this can't be decided on a per-mechanism basis, not without first modifying GSS sign
Re: [openssl-users] [openssl-dev] Kerberos
On 08/05/15 09:40, Matt Caswell wrote: > > > On 08/05/15 02:28, Jeffrey Altman wrote: > >> Regardless, the inability to improve the support in this area has left >> the those organizations that rely upon 2712 with the choice of use >> insecure protocols or re-implement the applications. I do not believe >> that any sane OS or application vendor can with a straight face continue >> to ship 2712 support. As such it should be removed from OpenSSL master. > > I plan to start preparing the patches to remove it next week. FYI, these patches have now been applied to master. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 2nd client connects to 1:1-server leads to client crash
Hello everyone, I have a server that is supposed to accept only one client. The connection works just fine. When I tried to connect to the server with a second client while another connection is already active, I expected that the 2nd client would return some error code, but instead it crashes completely. I am using non-blocking sockets for both clients (i.e. both clients are the same application, but different instances). Interestingly it doesn't crash during the connect call, but during the call to SSL_connect. My non-blocking socket attempts to connect until either an error happens or WSAEISCONN is returned (i.e. connect request was mande on an already connected socket), so it seems to connect even though the server isn't waiting for a connection anymore. In most cases it crashes after I got an SSL_ERROR_WANT_READ from SSL_connect, sometimes it crashes before that. In some lucky cases I get error code 5 without it crashing, but in most cases the crash happens. My server looks pretty much like this one: https://www.cs.utah.edu/~swalton/listings/articles/ssl_server.c I.e. it waits for a connection and when a client connected it waits for a message, processes it and returns the result. Do I have to reprogram the server to actively refuse multiple connections? And why does the connect function work? I am using OpenSSL 1.0.2a. The client runs on Windows 7, the server on lUbuntu inside a VM on the same PC. Thanks in advance for the help! Cheers Alex ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RES: RES: Testing OpenSSL based solution
On 12/05/2015 22:50, Marcus Vinicius do Nascimento wrote:
I did some quick research and found this:
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
If my understanding is correct, the public key is (p, q, g, y).
The private key would be x, such that y = g^x mod p.
Is there some way to generate both public and private keys using
OpenSSL, based on p, q, g and y?
Not without finding a way to breaking DSA.
The whole point is you cannot get x from y.
However for your library to be any use at all,
it needs to already support that the
computer/user that runs it to verify
signatures don't know the private key
either.
So somewhere you should already have a way
to input ((p, q, g), y) and use that to
verify a signature.
*De:*openssl-users [mailto:openssl-users-boun...@openssl.org] *Em nome
de *Marcus Vinicius do Nascimento
*Enviada em:* terça-feira, 12 de maio de 2015 17:06
*Para:* openssl-users@openssl.org
*Assunto:* [openssl-users] RES: Testing OpenSSL based solution
Thanks for both answers.
I tried using Y as the public key, but ssl seems not to accept that.
Here is the error scenario:
From the FIP file:
[mod = 1024]
P =
fda5442483ccf7a12399d6c13d56ff882d689524f1885fcb7424e26da2d200a1657b631dcc74c73ecbd89fe42cc554b7062835c73d7203161e09742392b2b7c75253eea04a0b55d511646fbe2e81a9d80463e956527f8d6d42f4193984d5dcc6a8dadff80f31e44405840828581f013e074859b885908aaab30d87660bbaf8cb
Q = dc678f95c673538f74dcbf67a80454c843937795
G =
efd89f2dcf6e6a6a77cf18f238b2419de127864218eb4550c9e1a73085f97d7988322d7eea91590646373aa66f7a3d0994cb5ac741a19874eb9e79862b000e5978f3305bb70be4f987a12a686167316e663f4de995b36e74062e39a79a4b30e4d36977276e3d33c5165911d303d5682f8e0a96c510e1d9606d09b5573a675362
Msg =
58b7b3639a8d99babfe57f814024c5e7a0893bcf47b692768e6c11561796894b5f898bf5968ad85dae9019dbb24cd13759678f0edb0b687703a4a4e785e8b85293157593ab797e0eb338ff94474a9c8752c3a83edb5798aa221db73aec931bfd1be3d70781647215f6649874a825101eb325ee27f2a20a57145eb019f2a09993
Y =
808998aecbc5ab4679bf215e2166b371d249bb6e4bfc3404f2bcd2aaf61770851d236668252a11f061fb54067ddaa97ed7bf5a5c836db02e5b1f9f1a627ac1eb2dcfa484ed5fef383f4bae7aa18a3ef9ea94bab83439ccf261ec52529f298050b27df185eecccf8caa44b529c8fcbd88c6a33cc42b5b17244ea9e1099686a92b
R = 33bf9a15b6823e7c5583f94bcea2f0439a881f8c
S = 48feaff1ec4803fb88fdc70773d9ac7b84905d3a
Result = P
So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.
Converting Y to Base64 =
"gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQsn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs="
Reformatting in PEM format = "-BEGIN DSA PRIVATE KEY-
gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+
179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQ
sn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs=
-END DSA PRIVATE KEY-
"
Code that matters:
BIO * keybio = BIO_new_mem_buf(const_cast(key.c_str()), -1);
if (keybio == NULL)
{
errormsg = "Can not create DSA key";
return 0;
}
DSA *dsa = PEM_read_bio_DSAPrivateKey(keybio, &dsa, NULL, NULL);
if (dsa == NULL)
{
errormsg = "Can not read DSA key";
}
return dsa;
PEM_read_bio_DSAPrivateKey fails.
Am I missing something here?
*De:*openssl-users [mailto:openssl-users-boun...@openssl.org] *Em nome
de *Jakob Bohm
*Enviada em:* terça-feira, 12 de maio de 2015 15:42
*Para:* openssl-users@openssl.org
*Assunto:* Re: [openssl-users] Testing OpenSSL based solution
On 12/05/2015 20:10, Salz, Rich wrote:
You can't easily have test vectors for DSA signatures since they include a random.
Any test vector would have to include the random, and any API would have to be able to
accept the random as part of the "sign" API. Verification should be okay.
What Mr. Salz refers to by "Verification should be okay"
is probably this:
You can have test vectors in the form of known good
signatures with public keys listed in the test vector.
For DSA, those would be the (message, y, r, s) quads
mentioned by the OP (y is the public key, (r, s) is the
signature), depending on his class library, it might be
possible to reformat those vectors to the format used
by his code for real messages.
The importance of such test vectors is to detect if an
implementation is accidentally implementing a different
signature algorithm (such as accidentally appending a 0
byte to each message both during signing and
verification). This would not be detected by signing
and verifying sample messages with random parameters.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://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-
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it "GSS-2" (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. I am of cause aware that some existing mechanisms have both SASL native and GSS native bindings and that those bindings are mutually exclusive, such that one must decide at standardization time if the SASL native or GSS native form shall be used for interoperability. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. However I strongly suspect that using ALPN will cause practical conflicts with early HTTP/2 implementations and early ALPN implementations, as such early implementations are likely to only cater to that single use of ALPN. In contrast there are now multiple unrelated deployed TLS extensions, so that mechanism is more stable and more ready to handle new uses. We don't have to use the ALPN approach, and we don't have to support SASL. But see below. 2. The TLS client always begins by sending the first GSS/SPNego leg in a (new) TLS extension "GSS-2". This is incompatible with doing channel binding the GSS way. Instead we'd have to exchange MICs of the channel binding when the GSS context is fully established. (This is fine, of course, and not a criticism, just pointing this out.) This is why I specified the alternate ordering below. Note however that not all versions of all GSS implementations (notable the Microsoft SSPI variant) may support the GSS channel binding mechanism. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension "GSS-2" to confirm support. Well, presumably the first response GSS token should go here. No, see below. 4. The second and subsequent legs of the GSS handshake are sent as the sole contents of the first encrypted records, actual application data is not sent until the GSS handshake succeeds. Note that the first encrypted server to client record (containing the second leg) can be sent in the same protocol round trip as the second half of the TLS handshake. It is an open design issue if these TLS records should be tagged as application records or key exchange records. This is just as in the ALPN approach. They should be tagged as application records so that the implementation can be either at the application layer or in the TLS library. However if it is negotiated via a TLS extension rather than TLS 1.2+ ALPN, thenintegration in the TLS stack will be unavoidable anyway. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. Yep, however as this entails extra round trips, it is not the only option. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. However the early channel binding might save a leg. 7. If the client wants encryption of the first GSS leg, it can either abstain from including that leg in the first SPNego GSS leg, or it can send a 0-byte first leg and then send the real first SPNego leg in the first encrypted client o server record, with the server responding with the second leg in the first encrypted server to client record as before (but no longer in the same round trip as the second half of the TLS handshake). With the ALPN approach this is a given. However if the first leg need not be encrypted and need not know thechannel binding, it can be sent a round earlier. This can (I hope) be decided on a per mechanism basis, thus if a GSS mechanism need not know its channel binding until the second leg, implementations that can provide the binding to the GSS layer later can take advantage of it.
Re: [openssl-users] Testing OpenSSL based solution
> From: openssl-users On Behalf Of Marcus Vinicius do Nascimento
> Sent: Tuesday, May 12, 2015 16:50
> I did some quick research and found this:
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
> If my understanding is correct, the public key is (p, q, g, y).
You might want to look at the actual standard, FIPS 186, free from NIST
and referred to by wikipedia as well as easily searchable. The current
version is revision -4, but the basic logic of DSA hasn't changed since
"-0" (although the sizes used have increased).
Standardly a DSA public key is (parameters, y) where parameters is
(p, q, g {, seed, counter}) where the optional fields in the parameters
allow verification of the parameter generation process. OpenSSL does
not use that option, so it uses only p,g,q and y. See below.
> The private key would be x, such that y = g^x mod p.
> Is there some way to generate both public and private keys using OpenSSL,
> based on p, q, g and y?
You cannot recover the private key from the public key for any
secure PKC scheme used with appropriate sizes. DSA is a secure
scheme, and DSS and these test cases use appropriate sizes.
> De: openssl-users Em nome de Marcus Vinicius do Nascimento
> Enviada em: terça-feira, 12 de maio de 2015 17:06
> I tried using Y as the public key, but ssl seems not to accept that.
> From the FIP file:
> So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.
> Converting Y to Base64 =
> Reformatting in PEM format = "-BEGIN DSA PRIVATE KEY-
[doesn't work]
As above, the public key requires all of p,q,g and y, not just y.
The private key would require x as well, and you don't have x.
For public keys for _all_ algorithms in files including PEM
OpenSSL uses the format standardized by X.509 called
SubjectPublicKeyInfo or SPKI for short, which is an ASN.1
sequence containing an AlgorithmIdentifier which is a(nother)
sequence containing an OID identifying the algorithm and an
optional parameters field whose type depends on the algorithm,
followed by a BITSTRING containing a nested encoding of the
public key value relative to the parameters for that algorithm.
For DSA, the OID identifies DSA, the parameters are a sequence
of three INTEGERs for p,g,q, and the nested key encoding is
just an INTEGER. All elements in ASN.1 use a "TLV" (tag, length,
value) encoding, and INTEGER (thus) consists of a tag octet of 02
specifying integer, a length whose length itself varies depending
on the length it encodes, and a value field which for INTEGER is
a _signed_ big-endian binary number. Since the particular y
you tried to encode below happens to have a magnitude size of
1024 bits, a multiple of 8, it requires a leading sign octet of 00.
So does g in this case, and p and q by design (they are specified with
magnitude sizes which are multiples of 8, and indeed of 32).
See rfc 5280 for the generic SPKI format, and rfc 3279 (referenced there)
for the specifics for several algorithms including DSA.
Note that the PEM type is just "BEGIN/END PUBLIC KEY" (no DSA)
because as above the format handles all algorithms.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
