On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev"
wrote:
Could you please be more specific wrt. DRBG organization that in your
opinion could impact the UI?
> From your use-case:
On Tue, Aug 29, 2017 at 11:31:03AM +, Dr. Matthias St. Pierre wrote:
> > -Ursprüngliche Nachricht-
> > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von
> > Matt Caswell
> > Gesendet: Dienstag, 29. August 2017 12:17
> > An: openssl-dev@openssl.org
> > Betreff:
➢ I’d like to suggest that any approach other than “immediately mix the
received randomness into the RNG state” is bad. If a user does RAND_add() now,
as opposed to 100 source code lines before, there may be a reason for that.
I think the only way to do that in the DRBG model is to treat it
On 08/29/2017 01:50 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> IMHO this interface is a way for the user to improve the quality of the
> randomness it would get from the given RNG, *not* to replace (or diminish)
> its other sources. My proposal is to abolish this parameter, especially since
>
On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev"
wrote:
➢ I’d like to suggest that any approach other than “immediately mix the
received randomness into the RNG state” is bad. If a user does
On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev"
wrote:
➢ An other problem with the current implemenation is that the
➢ randomness parameter that's now given to RAND_add() is just
➢
IMHO this interface is a way for the user to improve the quality of the
randomness it would get from the given RNG, *not* to replace (or diminish) its
other sources. My proposal is to abolish this parameter, especially since now
it is simply ignored (and IMHO – for a good reason).
That's a
uri> Could you please be more specific wrt. DRBG organization that in your
opinion could impact the UI?
Are you talking about the UI API or something else?
No-no-no, just the UI API.
I used the term “UI” to emphasize that this is the “public” part of the API,
exposed to the
➢ IMHO this interface is a way for the user to improve the quality of the
randomness it would get from the given RNG, *not* to replace (or diminish) its
other sources. My proposal is to abolish this parameter, especially since now
it is simply ignored (and IMHO – for a good reason).
We
➢ An other problem with the current implemenation is that the
➢ randomness parameter that's now given to RAND_add() is just
➢ ignored, it assumes it's the same as the length.
For what it’s worth, this was done deliberately, make RAND_add and RAND_seed
equivalent.
I am skeptical of
In message <168cef3c-d655-47bf-9874-048308154...@ll.mit.edu> on Tue, 29 Aug
2017 19:04:48 +, "Blumenthal, Uri - 0553 - MITLL" said:
uri> uri> Could you please be more specific wrt. DRBG organization that in
your opinion could impact the UI?
uri>
uri> Are you
I now have Racoon2 working. Steve's comment made me think about the digests
used in Racoon2 and I went searching for any commands using SHA1. I found two
hardcoded as string "SHA1". I changed it to SHA256 and bobs-your-uncle.
I guess this is due to the phasing-out of the SHA1 hash which was not
> If, based on its value, OpenSSL may decide that it now got “enough” entropy
> and doesn’t need to
> pull more from other sources before serving randomness to requestors – then
> it is harmful.
> “Over-confidence” in this value by the caller can negatively impact the
> quality of the produced
On Tue, Aug 29, 2017 at 06:50:37PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev"
> wrote:
>
> ➢ An other problem with the current implemenation is
On Tue, Aug 29, 2017 at 01:05:21PM +, Dr. Matthias St. Pierre wrote:
>
> Currently it's only possible to customize the callbacks but not the
> deterministic algorithm. IMHO this is sufficient for the needs of a standard
> OpenSSL user who only wants control over the entropy source. A true
➢ But now we just ignore it and assume every bit with get contains 1
➢ bit of randomness and we're sundenly seriously overestimating the
➢ amount of randomness we're getting. This is a documented public API,
➢ you can't just go and ignore this parameter.
Sure I can. Because the
On Tue, Aug 29, 2017 at 08:38:09PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > If, based on its value, OpenSSL may decide that it now got “enough” entropy
> > and doesn’t need to
> > pull more from other sources before serving randomness to requestors – then
> > it is harmful.
> >
Hi everybody,
on the [openssl-dev] mailing list, there has been a long ongoing discussion
about the new RAND_DRBG API and comparing it with the old RAND_METHOD API (see
"[openssl-dev] Work on a new RNG for OpenSSL"). Two of the most controversal
questions were:
- Do we really need a new RNG
On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> Currently, the OpenSSL core members seem to be reluctant to make the
> API public, at least at this early stage. I understand Rich Salz's
> viewpoint that this requires a thorough discussion, because a public
> interface can't be easily changed
Hi all,
I need to correct my WTF comment - RTFM RSA_size return bytes. Sorry
LJB
> evp = PEM_read_PrivateKey(fp, NULL, NULL, NULL); #ifdef TEST RSA *rsa =
> EVP_PKEY_get1_RSA(evp); printf("\nRSA modulus: %d\n\n", RSA_size(rsa));
> #endif
>
> The output is: "RSA modulus: 512" (WTF!)
--
Hi all,
I've was able to get the private key from the HSM (added below). Testing it
from the commandline shows:
% openssl rsa -noout -check -in /etc/racoon2/Local/refB.pem
RSA key ok
Next I started from the default Racoon2 source code (20100526a) with NO
patches. It now reads the private key
➢ > Sure I can. Because the DRBG seeds from the system anyway
➢ You can't assume that will work for all users.
And for places where the systesm doen’t have enough randomness, there is
nothing we can do.
--
openssl-dev mailing list
To unsubscribe:
>> I *don’t want* OpenSSL to make *any* estimation of the amount of provided
>> entropy. All I want it to do is to mix these bits into the RNG state. It’s
>> *my* business how much entropy I’m providing – but I don’t want OpenSSL to
>> make any decision regarding pull from other entropy sources
> -Ursprüngliche Nachricht-
> Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt
> Caswell
> Gesendet: Dienstag, 29. August 2017 12:17
> An: openssl-dev@openssl.org
> Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
>
>
> On 29/08/17 10:45, Dr.
In message <0e062727611c44bb8039170bbec11...@ex13.ncp.local> on Tue, 29 Aug
2017 13:05:21 +, "Dr. Matthias St. Pierre"
said:
Matthias.St.Pierre> > Frankly, I cannot see anything wrong with making that a
public API. I
Matthias.St.Pierre> > wonder, though, if
dev asap. If there are problems with it we can always revert it before
it makes it into a release.
Someone on the OMC called that “flip-flopping” and seemed to be against this
kind of thing.
If we are going to have an additional API, then we should at least see a draft
of the header
> Essentially, the argument for your last remark is in-structure vtable
> vs refered to vtable. I tend to prefer the latter (and that's the
> usual OpenSSL pattern too, even though there are exceptions).
You are the experts and much more familiar with the code then I am. My role was
only to
In message on Tue, 29 Aug
2017 13:27:20 +, "Dr. Matthias St. Pierre"
said:
Matthias.St.Pierre> > Essentially, the argument for your last remark is
in-structure vtable
Matthias.St.Pierre> > vs refered to
On Tue, Aug 29, 2017, Richard Levitte wrote:
> I'm late in the game, having only followed the development very
> superficially...
>
> If I understand correctly, the RAND_DRBG API is really a completely
> separate API that has nothing to do with the RAND_METHOD API pers se,
> i.e. any association
In message <3a54fcefd17d4735920426d21b3b8...@ex13.ncp.local> on Tue, 29 Aug
2017 13:39:02 +, "Dr. Matthias St. Pierre"
said:
Matthias.St.Pierre> Just a sudden inspiration: If the RAND_DRBG becomes a truly
independent API it might be better to strip the RAND_
Getting the client connect right appears surprisingly messy when one
needs to cope with all kinds of network error situations including
domain name resolution issues and temporarily unreachable servers.
Both indefinitely blocking and non-blocking behavior (i.e., connection
I'm late in the game, having only followed the development very
superficially...
If I understand correctly, the RAND_DRBG API is really a completely
separate API that has nothing to do with the RAND_METHOD API pers se,
i.e. any association between the two is more or less "accidental"?
Frankly, I
Could you please be more specific wrt. DRBG organization that in your
opinion could impact the UI?
From your use-case: you want to add entropy into a specific DRBG. You want to
push it, as opposed to the DRBG “pull when needed” model. That’s an additional
API. Also from your
Could you please be more specific wrt. DRBG organization that in your opinion
could impact the UI?
NIST 90Ar1 seems specific enough on what functionality DRBG can provide to
users, and it doesn't seem like a very elaborate or rich interface. Why would
it change, regardless of what you may
On 29/08/17 15:02, Salz, Rich via openssl-dev wrote:
>
> dev asap. If there are problems with it we can always revert it before
> it makes it into a release.
>
> Someone on the OMC called that “flip-flopping” and seemed to be against this
> kind of thing.
>
> If we are going to have
I actually plan to work on most of not all the things you mention.
This will probably result in the API changing before it's made
public. I'm probably slow, so please be patient.
Kurt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
36 matches
Mail list logo