Hi Guys
Can anyone please provide some feedback on this?
Thanks in advance.
Regards
Nauman
From: Nauman Hameed
Sent: Tuesday, November 1, 2016 6:42 PM
To: 'openssl-users@openssl.org'
Subject: Key wrapping methods for NIST 800-38F
Hi Guys
We are using OpenSLL 1.0.2j with FIPS Object Module (F
On 30/09/2015 19:36, Salz, Rich wrote:
Did you miss the detail about the contribution agreement not granting any rights to
third parties until the OpenSSL Foundation has "published" the contribution.
No I didn't. They are free to post code as apache 2 and frequently rebase against
master. O
>Did you miss the detail about the contribution agreement not granting any
>rights to third parties until the OpenSSL Foundation has "published" the
>contribution.
No I didn't. They are free to post code as apache 2 and frequently rebase
against master. Or whatever they want. We don't have
On 30/09/2015 18:57, Salz, Rich wrote:
Speaking just for myself, and not my fellow team mates, I see no upside and
a lot of downsides to our hosting of "does not work" code contributions.
Especially for FIPS specific code. The originators of that code are free to give
it to anyone else at any tim
> Speaking just for myself, and not my fellow team mates, I see no upside and
> a lot of downsides to our hosting of "does not work" code contributions.
> Especially for FIPS specific code. The originators of that code are free to
> give
> it to anyone else at any time; they don't need us to do so
On 30/09/2015 16:17, Steve Marquess wrote:
On 09/30/2015 09:58 AM, Jakob Bohm wrote:
On 30/09/2015 15:34, Steve Marquess wrote:
On 09/30/2015 09:18 AM, Jakob Bohm wrote:
...
Under the new "contribution agreement" scheme, publishing such items
early would also make them available to users ...
On 09/30/2015 09:58 AM, Jakob Bohm wrote:
> On 30/09/2015 15:34, Steve Marquess wrote:
>> On 09/30/2015 09:18 AM, Jakob Bohm wrote:
>>> ...
>>>
>>> Under the new "contribution agreement" scheme, publishing such items
>>> early would also make them available to users ...
>> Publishing by someone els
On 30/09/2015 15:34, Steve Marquess wrote:
On 09/30/2015 09:18 AM, Jakob Bohm wrote:
...
Under the new "contribution agreement" scheme, publishing such items
early would also make them available to users ...
Publishing by someone else is fine, go for it. It would be nice to have
someone else p
On 09/30/2015 09:18 AM, Jakob Bohm wrote:
>...
>
> Under the new "contribution agreement" scheme, publishing such items
> early would also make them available to users ...
Publishing by someone else is fine, go for it. It would be nice to have
someone else publish FIPS module code, or validation
On 30/09/2015 14:28, Steve Marquess wrote:
On 09/30/2015 03:50 AM, Jakob Bohm wrote:
Dear Steve,
Have you considered that their contribution may be of value
to the next/future major version of the open source FIPS
module (which would presumably involve a fresh submission
under updated FIPS vali
On 09/30/2015 03:50 AM, Jakob Bohm wrote:
> Dear Steve,
>
> Have you considered that their contribution may be of value
> to the next/future major version of the open source FIPS
> module (which would presumably involve a fresh submission
> under updated FIPS validation rules).
>
> This would obv
Dear Steve,
Have you considered that their contribution may be of value
to the next/future major version of the open source FIPS
module (which would presumably involve a fresh submission
under updated FIPS validation rules).
This would obviously be a different code branch from
maintenance/change
On 09/28/2015 09:13 AM, John Foley wrote:
> On 09/23/2015 08:16 AM, Steve Marquess wrote:
>> John, let me elaborate on my comment above by noting that the Cisco
>> contribution includes a bunch of FIPS specific code for which there is
>> no counterpart on the master branch (i.e. no place to put it)
On 09/23/2015 08:16 AM, Steve Marquess wrote:
> John, let me elaborate on my comment above by noting that the Cisco
> contribution includes a bunch of FIPS specific code for which there is
> no counterpart on the master branch (i.e. no place to put it). A
> version which worked on master with all t
On 09/23/2015 07:09 AM, Steve Marquess wrote:
> On 09/22/2015 07:26 PM, John Foley (foleyj) wrote:
>> Pull request 368 has KDF support for FIPS:
>> https://github.com/openssl/openssl/pull/368
>>
>>
>> I've already updated libsrtp to use this API for FIPS compliance. We
>> would like to contribute
On 09/22/2015 07:26 PM, John Foley (foleyj) wrote:
> Pull request 368 has KDF support for FIPS:
> https://github.com/openssl/openssl/pull/368
>
>
> I've already updated libsrtp to use this API for FIPS compliance. We
> would like to contribute to other downstream projects as well. But it
> woul
Pull request 368 has KDF support for FIPS:
https://github.com/openssl/openssl/pull/368
I've already updated libsrtp to use this API for FIPS compliance. We would like
to contribute to other downstream projects as well. But it would help if
OpenSSL accepted this pull request.
-- Origina
On 09/22/2015 10:04 AM, Philip Bellino wrote:
> Hello,
>
> In pursuit of FIPS validation using OpenSSL 1.0.2a/ FIPS 2.0.9, we are
> required by our testing lab to perform KDF tests for TLS (see document
> NIST SP800-135, Rev 1 section 4.2).
>
>
>
> Could you please point us to where the source
Bonjour,
Hodie XIV Kal. Iun. MMIX, naveen.bn scripsit:
>Thank you for the reply. I was thinking that, if i ( A ) encrypt the
>data with the public key from the certificate obtained from B, can the
>intruder generate a private key using the public key from the same
>certifica
Dear Erwann ABALEA
Thank you for the reply. I was thinking that, if i ( A ) encrypt the
data with the public key from the certificate obtained from B, can the
intruder generate a private key using the public key from the same
certificate from B, which may lead to Man in Middle attack.
P
Hi,
Hodie XIV Kal. Iun. MMIX, naveen.bn scripsit:
> I have a question ? can we have one public key and two private keys.
You can (set d' to d+k.n with an integer k), but all the private keys
will be equivalent. Everything you encrypt to the public key can be
decrypted with either private key, and
21 matches
Mail list logo
