> We should have OID's for the things we implement
Sounds like a policy :)
Vote time?
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
___
openssl-project mailing list
openssl-project
No there is no policy. We should have OID's for the things we implement (
On 3/14/18, 6:28 PM, "Paul Dale" wrote:
Is there a policy about filling in missing OIDs in objects.txt?
I noticed that AES-128-XTS is in objects.txt but doesn't include an OID
even though the IEEE Security
Is there a policy about filling in missing OIDs in objects.txt?
I noticed that AES-128-XTS is in objects.txt but doesn't include an OID even
though the IEEE Security in Storage Working Group has defined one.
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61
Consider a hypothetical scenario of a large high performance multi-user
database. All connections are via TLS. A lot of other cryptographic
operations are done, some involving random numbers. This is an example where
the dual ec attack could have been partially mitigated with per TLS DRBGs.
On Wed, Mar 14, 2018 at 12:49:46PM +, Salz, Rich wrote:
> So is having a high-quality, lockless (per-thread) CSPRNG good enough for
> now? Phrased like that, I think so. We have enough other stuff to do. So
> +1 to Kurt's per-thread approach.
I think it's better than what we have in 1.1.0
No mention of whether or not this will apply to EVERYTHING in a program, or
will it be left to administrative guidance. Your thoughts, for example, on a
“FIPS mode” flag for SSL or SSL_CTX? At a minimum, that needs to be listed as
a stakeholder requirement (from Akamai).
From: "t...@openssl.
So is having a high-quality, lockless (per-thread) CSPRNG good enough for now?
Phrased like that, I think so. We have enough other stuff to do. So +1 to
Kurt's per-thread approach.
___
openssl-project mailing list
openssl-project@openssl.org
https:/
It is good that Tim hit the break and requested a discussion. That was
overdue and it is unfortunate that we did not start it much earlier. I
think Tim brought up to important points:
1. We need to to pause for a discussion to determine the direction to
go. Otherwise the DRBG implementation will b
https://wiki.openssl.org/index.php/FIPS_module_3.0
I've edited that to be closer to the list of items we are discussing and to
remove things which looked like commitments that are out of scope of our
current plans.
As always, feedback is welcome - but we have had a few people referencing
that out
