Re: Hypothesis to explain "error A2088: END directive required at end of file"

2014-02-12 Thread cmello
Same issue for me.

Any help is welcome.

Thanks!



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Hypothesis-to-explain-error-A2088-END-directive-required-at-end-of-file-tp42328p48495.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl-dev] SHA-3 availability

2014-02-12 Thread Erwann Abalea

Bonjour,

SHA3 is not standardized yet. Keccak has been chosen in the end, but its 
parameters are still debated.
I'm pretty sure that once those parameters are fixed in stone, there 
will be an implementation in OpenSSL.


--
Erwann ABALEA

Le 12/02/2014 11:29, Francis GASCHET a écrit :
The OFTP2 support group is going to start upgrading the cipher suite 
supported in OFTP2.
The proposal includes SHA-3, which is supported by Java 
implementations (BouncyCastle at least).

Is there some plan to support it in openSSL ?


Re: SHA-3 availability

2014-02-12 Thread Peter Waltenberg
Personally I'd advise against this until NIST publishes test vectors for the finalist.We already have:DES(_OLD) and DES.SHA0 and SHA1Rjindael and AES.NIST has a long track record of changing algorithms before going 'final' and the problem is that once people start using the 'bad' version of the algorithm, it has to be supported forever, and that causes interop AND security issues.If you really want to speed the adoption of SHA3 :), ask NIST to finalize the standard ?, until that happens it's a poison pill.Peter-owner-openssl-...@openssl.org wrote: -To: openssl DEV From: Francis GASCHET Sent by: owner-openssl-...@openssl.orgDate: 02/12/2014 08:45PMSubject: SHA-3 availability
  


  
  
Dear all,
  
  The OFTP2 support group is going to
start upgrading the cipher suite supported in OFTP2.
The proposal includes SHA-3, which
  is supported by Java implementations (BouncyCastle
  at least).
  Is there some plan to support it
in openSSL ?

Thanks and best regards,
  
-- 
  
  


SHA-3 availability

2014-02-12 Thread Francis GASCHET

  
  
Dear all,
  
  The OFTP2 support group is going to
start upgrading the cipher suite supported in OFTP2.
The proposal includes SHA-3, which
  is supported by Java implementations (BouncyCastle
  at least).
  Is there some plan to support it
in openSSL ?

Thanks and best regards,
  
-- 
  
  



RE: Diffie Hellman question

2014-02-12 Thread Leon Brits
Thanks for your reply.

> Are you, by chance, trying to derive secret from keypairs generated with
> *different* parameters? This cannot possibly work, of course. Both sides
> keypairs must be generated for same DH parameters.

OK, I guess the larger prime numbers of each group makes there parameters 
*different*.

Thanks,
LJB


[openssl.org #3262] Check-in 22392 needs to get into 1.0.1 stable

2014-02-12 Thread Parag Doke via RT
This is a request to pull in check-in 22392 into the 1.0.1 series of
OpenSSL builds.
The change is needed to add a linker flag to OpenSSL builds.
Unless added, OpenSSL builds with the FIPS module run into a fingerprint
mismatch issue.

The email discussion on openssl-dev list follows.
Thanks in advance,
Parag Doke
Save paper, save trees. Do not print emails/documents unless absolutely
necessary.


-- Forwarded message --
From: Dave Thompson 
Date: Tue, Feb 11, 2014 at 6:30 AM
Subject: FIPS2.0-Win /fixed fix?, was Re: Which OpenSSL version picked up
check-in 22392?
To: openssl-dev@openssl.org


> From: owner-openssl-...@openssl.org  On Behalf Of Parag Doke
> Sent: Sunday, February 09, 2014 01:16

> What is the right way to build FIPS compliant OpenSSL binaries? I
> assumed the right way was:
> 1) Build FIPS module (say 2.0.5) using VS2008.
> Going by your reply, this should already have the "/fixed" linker
> flag. I will search the FIPS module source tarball to find which file
> has this.

It is still in utll/pl/VC-32.pl but in a different line than for
FIPS1.2/Openssl0.9.8.

> 2) Configure OpenSSL (say 1.0.1e) with the following configure options:
> perl Configure VC-WIN32 fips --with-fipslibdir=
> And then call make:
> nmake /f ms\ntdll.mak
>
I think you're doing it right, though I can't confirm from experience.

> In this approach, I confirm that I see the mismatch error as discussed
> on thread:
> http://comments.gmane.org/gmane.comp.encryption.openssl.devel/18309
>
> When I patched OpenSSL 1.0.1e source (util/pl/VC-32.pl) and built it
> again, the problem was fixed.
>
> That led me to believe the change didn't make it to the 1.0.1
> branches. Either that, or the way I'm building is wrong :-).
>
The change certainly isn't in the FIPS-USING 1.0.1, that's clear from
just looking. From the discussion I thought that doing it on the FIPS module

should work without doing it on the caller, but maybe not. In fact thinking
about it, since the FIPS module is embedded in libeay32.dll it makes sense
it should be in the FIPS-USING build, but at this point you need a real dev
(which I'm not) to confirm.

> If this is the right way to build, should I request this list to patch
> 1.0.1 series?

Probably you should request the change, but via the request tracker
not the maillist. (Maillist messages can easily get lost.)

Certainly if it works for you, you can just use it. You are permitted
to change the FIPS-USING code compile and link as long as it follows
a few specific bits of the security policy, unlike the FIPS module itself
which per policy you can't modify at all even when it makes no difference.

> Thanks in advance,
> Parag Doke
>
> On 2/8/14, Dave Thompson  wrote:
> > I'm not a dev or even a real FIPSian, but I'll take a stab:
> >
> >
> >
> > The commit itself says branch_0_9_8_stable, and see it in 0.9.8 v and
> > later.
> > But I don't think it does any good
> >
> > there, because you don't want to build a FIPS module from a normal
tarball.
> > (It's not validated, so it's no better
> >
> > and perhaps worse than a plain non-FIPS library.) There is one release
on
> > the website of fips-1.2 after
> >
> > 2012-apr-15, 1.2.4, which clearly does not have the change (VC-32.pl
> > contents and timestamp unchanged).
> >
> >
> >
> > All of the fips-2.0* tarballs are well after 2012-apr and do add /fixed,
> > but
> > not exactly this way. They put
> >
> > it in a different place that looks to have the same result, but I don't
> > have
> > actual FIPS builds to verify.
> >
> >
> >
> >
> >
> > From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org]
> > On Behalf Of Parag Doke
> > Sent: Thursday, February 06, 2014 08:37
> > To: openssl-dev@openssl.org
> > Subject: *** Spam *** Which OpenSSL version picked up check-in 22392?
> >
> >
> >
> > Hello All.
> >
> > I'm new to this list. Just wanted to ask which OpenSSL version picked up
> > check-in 22392 ?
> >
> > Here is the change I'm interested in:
> > http://cvs.openssl.org/chngview?cn=22392
> >
> >
> > Context:
> >
> > Avoid rebasing dll so that the fingerprint mismatch issue does not show
up.
> > The discussion is on this link:
> > http://comments.gmane.org/gmane.comp.encryption.openssl.devel/18309
> >
> > I looked at the code for OpenSSL 1.0.1e and 1.0.1f, both did not have
this
> > change.
> >
> > Was it obsoleted by some other subsequent change ?
> >
> > Thanks in advance,
> >
> >
> > Parag Doke
> > Save paper, save trees. Do not print emails/documents unless absolutely
> > necessary.
> >
> >
>
>
> --
> Parag Doke
> Save paper, save trees. Do not print emails/documents unless absolutely
> necessary.
> _
> _
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org

_

RE: Diffie Hellman question

2014-02-12 Thread Leon Brits
Thanks for your reply.

> Can you provide the source for the problem that you're running into?

I cannot give the source code as it is now, but I will create a new test case 
using only the OpenSSL calls I make in this situation. I will post it or report 
back if I find an error.

Regards,
LJB