Re: [openssl-users] Problems with deriving EC public key from private

[Mike Blaguszewski]

On Dec 17, 2018, at 11:42 PM, Billy Brumley  wrote:
> 
> But 0.4% is suspiciously close to 1/256, so I'm willing to bet your
> problem surrounds your size assumptions in various functions. Check
> the manpage of e.g. EC_POINT_point2oct and grep for usage in the
> library, but the idea is to pass NULL first, then malloc, then pass
> that pointer. BN_bn2bin is different. Probably the size won't be fixed
> (e.g., there is a 1/256 chance you'll have one byte less, i.e. leading
> zero).

Thanks so much! That was exactly it. Switching from BN_bn2bin() to 
EC_KEY_priv2oct() resolves the problem. (As does BN_bn2binpad(), but using the 
more standard binary format seems preferable.) I will also look into 
pre-flighting the calls with a NULL buffer.

Mike

P.S. not sure why it crashed for you, but I’d guess some combination of 
different OpenSSL versions and an error return being ignored by the sample 
code. I appreciate you taking a look despite that.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with deriving EC public key from private

[Billy Brumley]

On Tue, Dec 18, 2018 at 12:07 AM Mike Blaguszewski  wrote:
>
> Some code of mine reads a NIST P256 private key from bytes and derives the 
> public key from it, and this derived public key is incorrect about 0.4% of 
> the time. I’ve attached a sample program that does the following.
>
> 1. Generate a key-pair of type NID_X9_62_prime256v1
> 2. Write the public and private components to memory
> 3. Read the private key back from memory, derive the public key, and write 
> that back out.
> 4. Compare this “round-tripped” public key to the public key generated in 
> step 2.
>
> The public key from step 2 almost always matches the public key from step 3, 
> but about 0.4% of the time they will differ. (The sample program runs a loop 
> to determine this.) Further experiments suggest it’s the 
> private_key_from_binary() function that is the problem, where I derive the 
> public key using EC_POINT_mul(). The sample program omits error checking, but 
> in the production code no errors are reported.
>
> Does anyone see a flaw in my logic, especially in how I’m deriving the public 
> key from the private key? Also let me know if this would be better submitted 
> as a GitHub issue, or even if it needs to be handled as a paid support 
> request.

The sample code just segfaults for me in the first iteration, before
really generating a key, so it's hard to test:

Program received signal SIGSEGV, Segmentation fault.
0x77a7e3e0 in pkey_set_type (pkey=0x380, type=408, str=0x0,
len=-1) at crypto/evp/p_lib.c:181
(gdb) bt
#0  0x77a7e3e0 in pkey_set_type (pkey=0x380, type=408,
str=0x0, len=-1) at crypto/evp/p_lib.c:181
#1  0x77a7e546 in EVP_PKEY_set_type (pkey=0x380, type=408) at
crypto/evp/p_lib.c:221
#2  0x77a7e663 in EVP_PKEY_assign (pkey=0x380, type=408,
key=0x557587c0) at crypto/evp/p_lib.c:249
#3  0x77a248fb in pkey_ec_keygen (ctx=0x55758760,
pkey=0x380) at crypto/ec/ec_pmeth.c:416
#4  0x77a80912 in EVP_PKEY_keygen (ctx=0x55758760,
ppkey=0x7fffdd18) at crypto/evp/pmeth_gn.c:107
#5  0x5046 in generate_ec_key () at foo.c:18
#6  0x5256 in main () at foo.c:73

But 0.4% is suspiciously close to 1/256, so I'm willing to bet your
problem surrounds your size assumptions in various functions. Check
the manpage of e.g. EC_POINT_point2oct and grep for usage in the
library, but the idea is to pass NULL first, then malloc, then pass
that pointer. BN_bn2bin is different. Probably the size won't be fixed
(e.g., there is a 1/256 chance you'll have one byte less, i.e. leading
zero).

So all the static 32 and 33 byte assumptions aren't holding.

Also BN_bn2bin and EC_KEY_oct2priv are not inverses of each other
IIRC. (The former is raw bytes, latter ASN1 encoding.)

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problems with deriving EC public key from private

[Mike Blaguszewski]

Some code of mine reads a NIST P256 private key from bytes and derives the 
public key from it, and this derived public key is incorrect about 0.4% of the 
time. I’ve attached a sample program that does the following.

1. Generate a key-pair of type NID_X9_62_prime256v1
2. Write the public and private components to memory
3. Read the private key back from memory, derive the public key, and write that 
back out.
4. Compare this “round-tripped” public key to the public key generated in step 
2.

The public key from step 2 almost always matches the public key from step 3, 
but about 0.4% of the time they will differ. (The sample program runs a loop to 
determine this.) Further experiments suggest it’s the private_key_from_binary() 
function that is the problem, where I derive the public key using 
EC_POINT_mul(). The sample program omits error checking, but in the production 
code no errors are reported.

Does anyone see a flaw in my logic, especially in how I’m deriving the public 
key from the private key? Also let me know if this would be better submitted as 
a GitHub issue, or even if it needs to be handled as a paid support request.

Thanks,
Mike



ec_key_example.cxx
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] A script for hybrid encryption with openssl

[Jakob Bohm via openssl-users]

On 17/12/2018 16:21, Nick wrote:

Hello,

I've written a script to try and work around openssl's lack of a way to encrypt
large files with public key or hybrid cryptography.  I gather SMIME works for
files < ~ 2.5GB but the current implementation cannot decrypt files larger than
this.

My use case is automated server back-ups, for which I need to back up
arbitrarily large files and copy the result to S3 for storage, but I don't want
to store a decryption key on the server. I contemplated splitting the archives,
except this seemed about as much work as writing something which stored an
encrypted one-time password with the payload and using symmetric encryption.

As I'm not really a crypto/security expert, I thought I'd post it here and ask
for some feedback on it.

https://github.com/wu-lee/hencrypt




A simpler way is to realize that the formats used by SMIME/CMS 
(specifically

the PKCS#7 formats) allow almost unlimited file size, and any 2GiB limit is
probably an artifact of either the openssl command line tool or some of the
underlying OpenSSL libraries.

It would be interesting to hear from someone familiar with that part of the
OpenSSL API which calls to use to actually do CMS signing/encryption (and
verification/decryption) of data too large to fit in available memory, 
and how

to handle the data length BER encoding for values larger than a size_t.

Anyway, setting up an alternative data format might be suitable if combined
with other functionality requiring chunking, such as recovery from
lost/corrupted data "blocks" (where each block is much much larger than
a 1K "disk block").


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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-users

[openssl-users] A script for hybrid encryption with openssl

[Nick]

Hello,

I've written a script to try and work around openssl's lack of a way to encrypt
large files with public key or hybrid cryptography.  I gather SMIME works for
files < ~ 2.5GB but the current implementation cannot decrypt files larger than
this.

My use case is automated server back-ups, for which I need to back up
arbitrarily large files and copy the result to S3 for storage, but I don't want
to store a decryption key on the server. I contemplated splitting the archives,
except this seemed about as much work as writing something which stored an
encrypted one-time password with the payload and using symmetric encryption.

As I'm not really a crypto/security expert, I thought I'd post it here and ask
for some feedback on it.

https://github.com/wu-lee/hencrypt

Thanks!

Nick
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to find the right bug

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Shreya Bhandare
> Sent: Monday, December 17, 2018 03:29

> i am very new to openssl and contributing to large code bases in general, I 
> did my first contribution
> to openssl which got me familiar with the process etc. It is time for me to 
> dig deeper and find a bug
> that actually helps me understand some part of code base and I'm having a 
> hard time to actually
> find such a bug

Have you looked through the open issues at 
https://github.com/openssl/openssl/issues? There are at least a few labeled 
"good first issue" (I'm not sure how many because I'm not enabling a bunch of 
scripts just to get github's filtering to work), and in any case there are 
plenty there to choose from.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Openssl async support

[ASHIQUE CK]

Hi all,

I have some queries regarding OpenSSL async operation.

Current setup
-
I have one* OpenSSL dynamic engine (with RSA and AES-GCM support) *and
linked it with *Nginx* server. Multiple *WGET* commands on the client side.

Current issue
-
  Since OpenSSL *do_cipher call *(the function in which actual AES-GCM
encryption/decryption happening) comes from one client at a time which is
reducing file downloading performance. So we need an *asynchronous
operation in OpenSSL* ie. we need multiple do_cipher calls at the same time
from which we should submit requests to HW without affecting the incoming
requests and should wait for HW output.

Queries

 1) Is there is any other scheme for multiple do_cipher calls at a time?.
 2) Any method to enable asynchronous call from OpenSSL?

Versions
-
Openssl - 1.1.0h
Nginx1.11.10
Wget 1.17.1

 Kindly support me. Please inform me if any more inputs needed. Thanks in
advance.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] AssAccess was passed with no amendments

[open...@foocrypt.net]

Kyle

Anyone in their rights minds understands the dangers with government key escrow 
systems and governments requesting back doors or delaying the remediation of 
existing zero days, local and remote exploits so that they can utilise them for 
their own intelligence or law enforcement purposes.

From FooCrypt’s perspective, FooCrypt utilises OpenSSL as an engine calling the 
binary via an exec rather than calling a purposely built library from the 
OpenSSL source code. This has added security as it enables the end user to 
select an appropriate version of the engine that they have access to as per 
their own countries legal requirements around encryption software. FooCrypt is 
distributed on macOS platforms as a read only disk image, on linux and windows 
systems as a Debian package, and as a customised SOE in a read only bootable 
Live ISO file which can be burnt to an old fashioned DVD, and booted via a VM 
or on cut down hardware with no physical disk / network / bluetooth etc. The 
encrypted data objects can be sent via any messaging service / email / snail 
mail postage / fax / protocol / etc. Technically, if an end user, utilised the 
Live ISO on a blackbox system, with a deadman switch on the power, there is no 
way to ‘escrow’ they keys for anyone.

Not only is AssAccess an affront to the sanity of those who are left in 
Australia still managing to work in the encryption space since they 
criminalised encryption under the Defence Trade Acts additions of encryption 
into the Defence Strategic Goods Listing, it has been politicised by our 
degenerate LNP government with make believe claims that have no founding and 
belittles those with any technical understanding of the issues.

From a users perspective, end users should be able to ‘trust’ the encryption 
software they use and not have to deal with the perception of ‘back doors’ 
requested by Governments, which can’t be reported by those who are crunchy the 
code, as the Government is threatening them with a 5 year jail term and massive 
fines for disclosing the Governments attempts to circumvent security.







> On 17 Dec 2018, at 17:32, Kyle Hamilton  wrote:
> 
> Getting the key for any given communication from OpenSSL is definitely doable 
> if you're not using an engine.  If you are using an engine, it may or may not 
> be even possible.
> 
> In any case, maintaining that key once you have it is definitely out of scope 
> of OpenSSL. As an app developer subject to that law, it is up to you to 
> figure out a way to keep it available for compliance purposes.
> 
> I'm not part of the OpenSSL team, so I have no capacity to make a policy 
> statement on their behalf.  However, I'm pretty sure that OpenSSL is not 
> going to alter its API or its library design to make it easier for a bolt-on 
> AusAssAccess module to be written that directly queries the state of the 
> library or its structures.
> 
> That said, in the past it's been bandied about that an originating software 
> package subject to the law could encrypt the symmetric key not only to the 
> intended recipient, but also to a hardcoded compliance key.  A receiving 
> software package subject to the law would have to modify its receipt process 
> to store a copy of the symmetric key elsewhere when it first decrypted a 
> message -- probably also encrypted to a hardcoded compliance key.
> 
> The downside is "what happens when that compliance key is compromised"?  (or, 
> for that matter, if the compliance key is lost.)  And it will be compromised 
> or lost, someday, some way.  That's the reason so many people have been 
> against backdoors like this -- the security of the system is good, but the 
> security of human beings tasked with maintaining the security of the system 
> is nowhere near as good.
> 
> -Kyle H
> 
> On Fri, Dec 14, 2018, 18:20 open...@foocrypt.net 
>    wrote:
> Rather than going down the political or policy line, perhaps it may be 
> prudent to discuss the technical solutions to testing the engine, regardless 
> of the OS it is running on.
> 
> How does one validate and test the engines during / after compile to ensure 
> their ‘trust’ ?
> 
> 
> 
> > On 15 Dec 2018, at 10:42, Viktor Dukhovni  > > wrote:
> > 
> >> On Dec 14, 2018, at 5:42 PM, bmeeke...@buckeye-express.com 
> >>  wrote:
> >> 
> >> I simply wanted a clear statement so I can make an informed decision 
> >> whether or not I should use OpenSSL in future projects.  I now have my 
> >> answer.  Thank you.
> > 
> > This is not the right forum for that question.  The bill is too
> > new for a policy response to have been considered or agreed.
> > 
> > OpenSSL has committers from many countries.  OpenSSH also
> > has an Australian maintainer, have they published a policy?
> > 
> > I am sure there are Australian contributors to Linux, NetBSD,
> > FreeBSD, OpenBSD, Android, ...
> > 

Re: [openssl-users] RSA Public Key error

[Erwann Abalea via openssl-users]

Bonjour,

Without knowing what functions you’re calling when you try to encrypt data 
using the key Key3_wo16, I can only guess. And I’m guessing that you’re calling 
a function that expects to find a public key encoded in a SubjectPublicKeyInfo 
structure, and since this Key3_wo16 object is not such a structure, the 
function fails.

What you can do is :

  *   Take your public keys (for example Key2_w16)
  *   Check that the first 16 bytes are what you expect to have
  *   Pass the remainder of the file to the d2i_RSAPublicKey() function
  *   Use the resulting RSA public key the way you want

Cordialement,
Erwann Abalea


De : prithiraj das 
Date : lundi 17 décembre 2018 à 08:23
À : Erwann Abalea , "openssl-users@openssl.org" 

Objet : Re: [openssl-users] RSA Public Key error

Hi Erwann/All,

Thank you for your earlier response. I have done a couple of tests on the 
originally generated 2048-bit RSA public key (let's say Key1_org) and the key 
file containing 16 byte custom information after removing 24 bytes from the 
originally generated key file and prepending those 16 bytes (let's say 
Key2_w16). For my experiment(s), I also removed those 16 bytes from the key 
Key2_w16 (which contains custom information) and the rest of the bytes were 
written into a file. Lets name this keyfile Key3_wo16. I believe the presence 
of custom 16 byte information resulted in asn1parse encoding/decoding errors as 
mentioned in the previous mail..

So now, Key3_wo16  =  Key2_w16 - the first 16 bytes  =   Key1_org - the first 
24 bytes. And  I performed asn1parse on Key3_wo16. The output of asn1parse on 
this key is shown in the image file asn1parse of 24 byte removed.jpg which is 
attached in the mail. And I also performed 2 asn1parse strparse opertions on 
the originally generated public key Key1_org with strparse offsets 19 and 24. I 
have attached screenshots of the same with names asn1parse strparse 19.jpg and 
asn1parse strparse 24.jpg respectively. The outputs in all cases are the same. 
In the screenshots, the (removed/blurred) respective INTEGER values in all 
screenshots are the same.

What I want to know is why is OpenSSL throwing an error when try to encrypt 
data using the key Key3_wo16? The same command used for encryption works when 
the key Key1_org is used. I believe the INTEGER values contain the modulus and 
exponent information and so, I was expecting the encryption to be successful 
but OpenSSL fails to accept this key.

Can anyone please tell me what is going wrong here? Apart from the solution 
suggested by Erwann , can anyone please suggest an alternative solution as we 
need to work with the Key2_w16 ( the key containing the custom 16 byte 
information after removing the originally present first 24 bytes)? That is the 
only keyfile received by us.

Thanks and Regards,
Prithiraj

On Wed, 12 Dec 2018 at 12:32, Erwann Abalea via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Bonjour,

Assuming the first 24 bytes you’re talking about are the very beginning of the 
SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), 
that means you’ve replaced up to the first byte of the BITSTRING containing the 
public key (this byte indicates the number of unused bits) for a 2048bits RSA 
key with 16 custom bytes.
That’s perfectly normal for OpenSSL to refuse to load that beast, and for 
asn1parse to return errors (the first bytes do not represent a correct DER 
encoding of anything).
Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my 
own, and now I can’t open the file again ». Those bytes are there for a reason.

A quick solution would be to *add* your 16 bytes before the public key, and 
remove them when passing the rest of the bytes to OpenSSL.

Cordialement,
Erwann Abalea


De : openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
au nom de prithiraj das 
mailto:prithiraj@gmail.com>>
Répondre à : "openssl-users@openssl.org" 
mailto:openssl-users@openssl.org>>
Date : mercredi 12 décembre 2018 à 08:08
À : "openssl-users@openssl.org" 
mailto:openssl-users@openssl.org>>
Objet : [openssl-users] RSA Public Key error

Hi,

I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That 
key has been obtained after removing the first 24 bytes from the originally 
generated RSA public key. Those 24 bytes are being replaced by some custom 16 
byte information which is being used as some sort of identifier in some future 
task and those 16 bytes are playing no role in encryption. OpenSSL fails to 
read this key. asn1parse shows some parsing error and most importantly RSA 
encryption in OpenSSL using this key fails. The untampered version of the RSA 
public key generated from the same source and containing the original 24 bytes 
at the beginning of the key is successfully read by OpenSSL and the RSA 
encryption using that key is also successful in OpenSSL. But our 

[openssl-users] How to find the right bug

[Shreya Bhandare]

Hello,

i am very new to openssl and contributing to large code bases in general, I
did my first contribution to openssl which got me familiar with the process
etc. It is time for me to dig deeper and find a bug that actually helps me
understand some part of code base and I'm having a hard time to actually
find such a bug, any help in pointing out a bug that that any of you have
come across, that you think would be a good start or something that you're
not finding time to do, I would be happy to do it (with a little help). Or
any help on pointers on how to find the right bug for you when you don't
know much about the code base would also be very helpful, i wouldn't want
to take up much time of anybody :)

Also i wans't sure which of the mailers was the more appropriate one to
post this question so adding both, won't happen the next time!


Thanks,
Shreya
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users