Re: Reg solaris support for openssl 1.1.1b

[ramakrushna mishra]

>
> Hi All,
>

Thanks for your responses.
I am able to build openssl 1.1.1 on my solaris and able to run "openssl
version".
I followed the same procedure for openssl 1.1.1b and when I run "openssl
version"  seeing the mentioned error. i.e
"ld.so.1: openssl: fatal: relocation error: file openssl: symbol
OPENSSL_sk_new_null: referenced symbol not found
Killed
".

So, How come it works with openssl 1.1.1 and not with 1.1.1b.
I am using the same machine and same procedure to configure and install it.
So, Is there anything different that need to be done for 1.1.1b version ?

Thanks and Regards,
Ram Krushna


>
> On Sat, Mar 16, 2019 at 6:20 AM  wrote:
>
>> Send openssl-users mailing list submissions to
>> openssl-users@openssl.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>> or, via email, send a message with subject or body 'help' to
>> openssl-users-requ...@openssl.org
>>
>> You can reach the person managing the list at
>> openssl-users-ow...@openssl.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openssl-users digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
>>5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
>>
>>
>> --
>>
>> Message: 1
>> Date: Fri, 15 Mar 2019 18:19:53 +0100
>> From: Jakob Bohm 
>> To: openssl-users@openssl.org
>> Subject: Re: Reg solaris support for openssl 1.1.1b
>> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd...@wisemo.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 15/03/2019 14:33, Dennis Clarke wrote:
>> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> >> My guess is that your binary is loading the system's shared libraries.
>> >> To find out whether this is the case, try
>> >>
>> >>  ??? ldd bin/openssl
>> >>
>> >> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> >> explicitely.
>> > Actually LD_LIBRARY_PATH is evil.
>> >
>> > The correct way to do this is to compile with a RUNPATH set in the
>> > output ELF files.
>> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
>> testing
>> a newly compiled binary before installing the libraries to their final
>> locations, perhaps
>> on the same, perhaps on another machine.
>>
>> P.S.
>> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
>> RUNPATH as
>> presumed by the above answer.
>>
>> 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
>>
>>
>>
>> --
>> Message: 5
>> Date: Fri, 15 Mar 2019 20:49:30 -0400
>> From: Dennis Clarke 
>> To: openssl-users@openssl.org
>> Subject: Re: Reg solaris support for openssl 1.1.1b
>> Message-ID: <4b08232c-f734-987c-814c-5acef59f4...@blastwave.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
>> > On 15/03/2019 14:33, Dennis Clarke wrote:
>> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> >>> My guess is that your binary is loading the system's shared libraries.
>> >>> To find out whether this is the case, try
>> >>>
>> >>>  ldd bin/openssl
>> >>>
>> >>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> >>> explicitely.
>> >> Actually LD_LIBRARY_PATH is evil.
>> >>
>> >> The correct way to do this is to compile with a RUNPATH set in the
>> >> output ELF files.
>> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
>> > testing
>> > a newly compiled binary before installing the libraries to their final
>> > locations, perhaps
>> > on the same, perhaps on another machine.
>> >
>> > P.S.
>> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override
>> > RUNPATH as
>> > presumed by the above answer.
>>
>> Yes it certainly does. Otherwise testing a new custom lib would be a
>> royal pain as opposed to just a pain.  Also most people still, after
>> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
>> of breath trying to explain it after decades of watching folks skewer
>> themselves over and over and over 
>>
>> dc
>>
>>
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> openssl-users mailing list
>> openssl-users@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>> --
>>
>> End of openssl-users Digest, Vol 52, Issue 19
>> *
>>
>

Re: Internal IP Exposed

[Kyle Hamilton]

That's a configuration issue with the servers, not an issue with the
openssl command itself.

There's no information on what the back-end HTTP server software is
being used.  If it were Apache, there would be a ServerName directive
that could change the server's idea of what name it should refer to
itself as.  I don't have information on other server software
configuration.

-Kyle H

On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
 wrote:
>
> Hi all,
>
> New to the mailing list and a complete newbie to openssl and the likes. 
> There's a ticket by a client that I'm new at and he claims that there's a 
> security problem with the openssl command to his servers.
>
> Internal IP exposed after running a openssl (version 1.1.0j) connect command:
>
> openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
>
> Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, 
> typed the following:
>
> GET /images HTTP/1.0
>
> And hit enter twice, the following gets displayed:
>
> HTTP/1.0 301 Moved Permanently
> Date: Mon, 25 Mar 2019 00:10:13 GMT
> Server: -x
> Location: https://10.240.123.1:10443/images/
> Connection: close
> Content-Type: text/html; charset=utf-8
> X-Frame-Options: SAMEORIGIN
> Content-Security-Policy: frame-ancestors 'self'
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Strict-Transport-Security: max-age=28800
>
> 
> 
> 301 Moved Permanently
> 
> Moved Permanently
> The document has moved  HREF="https://10.240.123.1:10443/images/;>here.
> 
> read:errno=0
>
> The 10.240.123.1 is an internal IP and it is exposed by this little method. 
> Although not shown when using curl -kv -O command.
>
> Is there a way to cover up the "Location" or at least the internal IP from 
> being exposed? Thanks.
>
> Sorry if this isn't clear or if this is the wrong place to ask this.
>
> --
> Abdul Qoyyuum Bin Haji Abdul Kadir
> HP No: +673 720 8043

Re: aes-cbc-256 mode descryption without an IV

[Tim Webber]

Good fine Marian.  Thx for all your help.

On Mon, Mar 25, 2019 at 9:24 AM Marian Beermann  wrote:

> As it just so happens here is a gist implementing EVP_BytesToKey in Python:
> https://gist.github.com/tly1980/b6c2cc10bb35cb4446fb6ccf5ee5efbc
>
> -Marian
>
> Am 25.03.19 um 17:14 schrieb Tim Webber:
> > Thanks Marian.  i did read the man pages for enc .  not sure how that
> > gets you to the  EVP_BytesToKey algorithm but thank you for providing
> > that page.  i suspect it might be easier to have the folks encrypting
> > the data specifiy an IV rather than trying to figure out how to
> > implement  EVP_BytesToKey in python.  its not inconsequential.
> >
> > On Mon, Mar 25, 2019 at 5:08 AM Marian Beermann  > > wrote:
> >
> > Well let's just read the man pages, shall we?
> >
> > >-kfile filename
> > > Read the password to derive the key from the first line of
> filename.
> >
> > Then
> >
> > >-md digest
> > > Use the specified digest to create the key from the passphrase.
> > > The default algorithm is sha-256.
> >
> > And
> >
> > >   -iv IV
> > > ...
> > > When a password is being specified using one of the other options,
> the
> > IV is generated from this password.
> >
> > The man page doesn't specify the key derivation algorithm, but a
> quick
> > glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
> > documented here:
> > https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html
> >
> > -Marian
> >
> > Am 25.03.19 um 01:20 schrieb Tim Webber:
> > > I just posted a message which i have copied below to a python
> > forum.  It
> > > might be better asked here.  The coles notes version of my
> > question is this:
> > >
> > > I have received an encrypted data file (mydata.encrypted) and a key
> > > (plain text for now) and the following command to decrypt it:
> > >
> > > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> > > mydata.decrypted -kfile my_symmetric_key
> > >
> > > Question is this.  How is the initialization vector calculated?
> This
> > > command works fine.  My issues is that i dont know how the
> > > initialization vetor is calculated.  I suspect if its left out
> > there is
> > > some default way of doing it.  Can you tell me how its done?
> Thanks!
> > >
> > > * ORIGINAL QUESTION to python community
> > > **
> > >
> > > I have received an encrypted data file (mydata.encrypted) and a key
> > > (plain text for now) and the following command to decrypt it:
> > >
> > > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> > > mydata.decrypted -kfile my_symmetric_key
> > >
> > > The people who encrypted these data did so with openssl but I dont
> > know
> > > what the encrypt command looks like. I do know that the above
> command
> > > does decrypt the data successfully though.
> > >
> > > I want to use Python to decrypt this file. I am thinking of using
> > > cryptodome but am open to suggestions. Here's what i know from the
> > above
> > > openssl decrypt command.
> > >
> > > - its uses AES cbc 256 mode for the decryption ( -d )
> > > - it uses base64 to encode the data "AFTER" (-a) the cryptographic
> > operation
> > > - it does not specify the initialization vector (IV).
> > >
> > > I am struggling with how to code for this using python. What I
> suspect
> > > is my problem is that i dont know how to properly calculate the IV.
> > > Looking at the openssl documentation they say to see "key
> > derivation" to
> > > find out how they handle IV when its not specified. I cant track
> down
> > > this key derivation information. Any help will be appreciated!
> > > ***
> >
>
>

Re: Using RSA-PSS in OpenSSL 1.1.1b

[Viktor Dukhovni]

On Tue, Mar 26, 2019 at 12:25:21AM +0100, Tobias Nießen wrote:

> I am using OpenSSL 1.1.1b and I have two questions regarding RSA-PSS. I 
> am using the following command to generate the private key:
> 
>  $ openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 \
>-pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 \
>-pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt \
>rsa_pss_keygen_saltlen:16 -out rsa_pss_private_2048_restricted.pem
> 
> This works, but I am unsure how to produce the corresponding public key 
> using the openssl CLI, it would be great if someone could give me some 
> pointers.

$ openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 \
-pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 \
-pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt 
rsa_pss_keygen_saltlen:16 \
-out rsa_pss_private_2048_restricted.pem
+
...+
$ openssl pkey -in rsa_pss_private_2048_restricted.pem -pubout |
  openssl pkey -pubin -text
-BEGIN PUBLIC KEY-
MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAaEaMBgGCSqGSIb3DQEB
CDALBglghkgBZQMEAgGiAwIBEAOCAQ8AMIIBCgKCAQEAtfBYSSrOvPmuwVzRJeOP
h5o9iZEM2L9CTY3mJRW5cJOdoOwjEp6ITge3QxPbgoFlKwg88U1ejIj7/uNwZKIV
yO5WRYRBFxS+rdBv6gQNyBn6z4LcxQ1chE6PgpmO0ZsDj56aRumf7mmg5ewFHOAG
txeSRyT4NO6XMFb57OGGqGwhYm/nUrbrtmErCc8Y/HKP0TVHCnrvoGf2hgAkmvYG
FxqbXs12nQrgcecPZVtszcdD/RelTaE62TnNrsHOCEdqLoOXTJ/64LQXKFrbAd7H
YiBKXYA+PkJf5a053LJ9gIJlkYKpCbXqkI9cLRS/uX5WDg5/rJilR8Ng77tQSJvq
LwIDAQAB
-END PUBLIC KEY-
RSA-PSS Public-Key: (2048 bit)
Modulus:
00:b5:f0:58:49:2a:ce:bc:f9:ae:c1:5c:d1:25:e3:
8f:87:9a:3d:89:91:0c:d8:bf:42:4d:8d:e6:25:15:
b9:70:93:9d:a0:ec:23:12:9e:88:4e:07:b7:43:13:
db:82:81:65:2b:08:3c:f1:4d:5e:8c:88:fb:fe:e3:
70:64:a2:15:c8:ee:56:45:84:41:17:14:be:ad:d0:
6f:ea:04:0d:c8:19:fa:cf:82:dc:c5:0d:5c:84:4e:
8f:82:99:8e:d1:9b:03:8f:9e:9a:46:e9:9f:ee:69:
a0:e5:ec:05:1c:e0:06:b7:17:92:47:24:f8:34:ee:
97:30:56:f9:ec:e1:86:a8:6c:21:62:6f:e7:52:b6:
eb:b6:61:2b:09:cf:18:fc:72:8f:d1:35:47:0a:7a:
ef:a0:67:f6:86:00:24:9a:f6:06:17:1a:9b:5e:cd:
76:9d:0a:e0:71:e7:0f:65:5b:6c:cd:c7:43:fd:17:
a5:4d:a1:3a:d9:39:cd:ae:c1:ce:08:47:6a:2e:83:
97:4c:9f:fa:e0:b4:17:28:5a:db:01:de:c7:62:20:
4a:5d:80:3e:3e:42:5f:e5:ad:39:dc:b2:7d:80:82:
65:91:82:a9:09:b5:ea:90:8f:5c:2d:14:bf:b9:7e:
56:0e:0e:7f:ac:98:a5:47:c3:60:ef:bb:50:48:9b:
ea:2f
Exponent: 65537 (0x10001)
PSS parameter restrictions:
  Hash Algorithm: sha256
  Mask Algorithm: mgf1 with sha256
  Minimum Salt Length: 0x10
  Trailer Field: 0xBC (default)

> I also need to access the key restrictions (MD / MGF1 MD / salt length) 
> given only a pointer to the EVP_PKEY structure. I understand that the 
> information is stored in the RSA_PSS_PARAMS structure. How do I access 
> the restrictions using the public API?

EVP_PKEY_get0_RSA() gets you the underlying algorithm-specific RSA
key.  But there don't appear to be any accessors that use the
internal rsa_pss_get_param() function to return these parameters
(I could not find any).  Perhaps open an issue on github, or if
you are up for it, a pull request (with documentationa and code).

-- 
Viktor.

Using RSA-PSS in OpenSSL 1.1.1b

[Tobias Nießen]

Hello,

I am using OpenSSL 1.1.1b and I have two questions regarding RSA-PSS. I 
am using the following command to generate the private key:


    openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 
-pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 
-pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt 
rsa_pss_keygen_saltlen:16 -out rsa_pss_private_2048_restricted.pem


This works, but I am unsure how to produce the corresponding public key 
using the openssl CLI, it would be great if someone could give me some 
pointers.


I also need to access the key restrictions (MD / MGF1 MD / salt length) 
given only a pointer to the EVP_PKEY structure. I understand that the 
information is stored in the RSA_PSS_PARAMS structure. How do I access 
the restrictions using the public API?


Thanks in advance!
Tobias

Re: install error with linux mint 19.1

[Jakob Bohm via openssl-users]

On 25/03/2019 22:53, sebastien wrote:


hi

in a terminal I've got this error with

|openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: 
version `OPENSSL_1_1_1' not found (required by openssl) openssl: 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' 
not found (required by openssl) can you please help me ? |

I guess the files |/usr/lib/x86_64-linux-gnu/libssl.so.1.1 and
||/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1|||are the system installed
OpenSSL 1.1.0 libraries and your freshly compiled openssl 1.1.1
program is is trying to load them instead of it's own version 1.1.1
libraries.

If so, try testing withthe command

LD_LIBRARY_PATH=/home/your/openssl-1.1.1-build-dir/somewhere openssl version

to force use of your not-yet-installed OpenSSL 1.1.1 libraries.

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

install error with linux mint 19.1

[sebastien]

hi

in a terminal I've got this error with

|openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: 
version `OPENSSL_1_1_1' not found (required by openssl) openssl: 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not 
found (required by openssl) can you please help me ? |

RE: Using (not building) openssl with mingw on Windows 10

[Kenneth Goldman]

> From: Michael Wojcik 

> Without picking at the problem files myself, not really. It's
> probably something that will be fairly obvious in retrospect but I'm
> not seeing it from here.
>
> The import libraries (I'm assuming libssl.lib is one as well, on
> your system) basically tell the linker "for this symbol, insert a
> runtime load reference to this DLL". The Cygwin nm can display the
> symbols in an import library; I don't remember if MingW includes nm,
> or know if it understands import libraries.
>
> So well-formed import versions of libcrypto.lib and libssl.lib
> should name all the public OpenSSL symbols, and you shouldn't get
> resolution errors when linking against them. You might well get
> resolution errors at runtime, if the corresponding DLLs can't be
> found; but not a link time.

Here's a new attempt.  I added -lcrypto.  I also added -L and the path to
libcrypto.lib.

The error makes sense because -lcrypto should search for libcrypto.a, and
there is none in the Shining Light build.

I also tried pointing directly to "c:/program
files/openssl64/lib/libcrypto.lib", but the link failed.

~~

"c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o
libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o
tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o
tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o
CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o \
-Wl,--out-implib,libibmtss.a -L"c:/program files/openssl64/lib"
-lcrypto "c:/program files/MinGW/lib/libws2_32.a"

c:/program
files/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe:
cannot find -lcrypto

Re: ECC keypair generation with password

[Kenneth Goldman]

> From: Viktor Dukhovni 
> >
> > In the script, I used this:
> >
> > openssl ec -aes128 -passout pass: -in tmpecprivkeydec.pem
> -out tmpecprivkey.pem
>
> I try to avoid putting sensitive information in command-line arguments.
>
> If you're using "bash" (which has "printf" as a built-in) you could use:
>
>-passout file:<(printf "\n")
>
> which does not create any processes with the password in the argument
vector.
> Example:
>
> $ openssl enc -aes128 -pass file:<(printf "\n") < enc -d -aes128 -pass file:<(printf "\n")
> > foobar
> > EOF
> foobar

Understood, but this is just for a regression test script.

Thanks.

Re: ECC keypair generation with password

[Viktor Dukhovni]

> On Mar 25, 2019, at 1:53 PM, Kenneth Goldman  wrote:
> 
> 
> $ openssl ec -aes128 < 
> This was the piece I was missing.  Thanks.
> 
> In the script, I used this:
> 
> openssl ec -aes128 -passout pass: -in tmpecprivkeydec.pem -out 
> tmpecprivkey.pem

I try to avoid putting sensitive information in command-line arguments.

If you're using "bash" (which has "printf" as a built-in) you could use:

-passout file:<(printf "\n")

which does not create any processes with the password in the argument vector.
Example:

$ openssl enc -aes128 -pass file:<(printf "\n") < foobar
> EOF
foobar

-- 
Viktor.

Re: aes-cbc-256 mode descryption without an IV

[Marian Beermann]

As it just so happens here is a gist implementing EVP_BytesToKey in Python:
https://gist.github.com/tly1980/b6c2cc10bb35cb4446fb6ccf5ee5efbc

-Marian

Am 25.03.19 um 17:14 schrieb Tim Webber:
> Thanks Marian.  i did read the man pages for enc .  not sure how that
> gets you to the  EVP_BytesToKey algorithm but thank you for providing
> that page.  i suspect it might be easier to have the folks encrypting
> the data specifiy an IV rather than trying to figure out how to
> implement  EVP_BytesToKey in python.  its not inconsequential.
> 
> On Mon, Mar 25, 2019 at 5:08 AM Marian Beermann  > wrote:
> 
> Well let's just read the man pages, shall we?
> 
> >        -kfile filename
> > Read the password to derive the key from the first line of filename.
> 
> Then
> 
> >        -md digest
> > Use the specified digest to create the key from the passphrase.
> > The default algorithm is sha-256.
> 
> And
> 
> >       -iv IV
> > ...
> > When a password is being specified using one of the other options, the
> IV is generated from this password.
> 
> The man page doesn't specify the key derivation algorithm, but a quick
> glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
> documented here:
> https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html
> 
> -Marian
> 
> Am 25.03.19 um 01:20 schrieb Tim Webber:
> > I just posted a message which i have copied below to a python
> forum.  It
> > might be better asked here.  The coles notes version of my
> question is this:
> >
> > I have received an encrypted data file (mydata.encrypted) and a key
> > (plain text for now) and the following command to decrypt it:
> >
> > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> > mydata.decrypted -kfile my_symmetric_key
> >
> > Question is this.  How is the initialization vector calculated?  This
> > command works fine.  My issues is that i dont know how the
> > initialization vetor is calculated.  I suspect if its left out
> there is
> > some default way of doing it.  Can you tell me how its done? Thanks!
> >
> > * ORIGINAL QUESTION to python community
> > **
> >
> > I have received an encrypted data file (mydata.encrypted) and a key
> > (plain text for now) and the following command to decrypt it:
> >
> > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> > mydata.decrypted -kfile my_symmetric_key
> >
> > The people who encrypted these data did so with openssl but I dont
> know
> > what the encrypt command looks like. I do know that the above command
> > does decrypt the data successfully though.
> >
> > I want to use Python to decrypt this file. I am thinking of using
> > cryptodome but am open to suggestions. Here's what i know from the
> above
> > openssl decrypt command.
> >
> > - its uses AES cbc 256 mode for the decryption ( -d )
> > - it uses base64 to encode the data "AFTER" (-a) the cryptographic
> operation
> > - it does not specify the initialization vector (IV). 
> >
> > I am struggling with how to code for this using python. What I suspect
> > is my problem is that i dont know how to properly calculate the IV.
> > Looking at the openssl documentation they say to see "key
> derivation" to
> > find out how they handle IV when its not specified. I cant track down
> > this key derivation information. Any help will be appreciated! 
> > *** 
> 

Re: Internal IP Exposed

[Jochen Bern]

On 03/25/2019 01:08 PM, openssl-users-requ...@openssl.org digested:
> Date: Mon, 25 Mar 2019 11:33:55 +1100
> From: Abdul Qoyyuum 
> 
> GET /images HTTP/1.0

Note that this is a HTTP 1.*0* request that doesn't require the client
to send a Host: header stating what *his* idea of "which server am I
trying to talk to?" is.

> HTTP/1.0 301 Moved Permanently
> Location: https://10.240.123.1:10443/images/

/images is a directory, which means that the client is supposed to ask
for "/images/" (with a trailing slash) to request a directory listing.

The server is helpfully sending back a HTTP Redirect to tell the client
what he *should* request instead, in the form of a complete URL, which
necessitates a host and port part. Having no idea who and what the
*client* expects to talk to, the server fills in what *it* knows - its
local (internal) IP and port. This "attack" already worked that way
almost 20 years ago, when I demonstrated it to some (horrified) bank IT
people on their Netscape-based online banking solution middleware ...

OpenSSL is not involved here, and whether (and what) you can do to close
the gap depends on what HTTP server (and, if present, reverse proxy
solution) you're using.

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect



smime.p7s
Description: S/MIME Cryptographic Signature

Re: aes-cbc-256 mode descryption without an IV

[Marian Beermann]

Well let's just read the man pages, shall we?

>-kfile filename
> Read the password to derive the key from the first line of filename.

Then

>-md digest
> Use the specified digest to create the key from the passphrase.
> The default algorithm is sha-256.

And

>   -iv IV
> ...
> When a password is being specified using one of the other options, the
IV is generated from this password.

The man page doesn't specify the key derivation algorithm, but a quick
glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
documented here:
https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html

-Marian

Am 25.03.19 um 01:20 schrieb Tim Webber:
> I just posted a message which i have copied below to a python forum.  It
> might be better asked here.  The coles notes version of my question is this:
> 
> I have received an encrypted data file (mydata.encrypted) and a key
> (plain text for now) and the following command to decrypt it:
> 
> openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> mydata.decrypted -kfile my_symmetric_key
> 
> Question is this.  How is the initialization vector calculated?  This
> command works fine.  My issues is that i dont know how the
> initialization vetor is calculated.  I suspect if its left out there is
> some default way of doing it.  Can you tell me how its done? Thanks!
> 
> * ORIGINAL QUESTION to python community
> **
> 
> I have received an encrypted data file (mydata.encrypted) and a key
> (plain text for now) and the following command to decrypt it:
> 
> openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> mydata.decrypted -kfile my_symmetric_key
> 
> The people who encrypted these data did so with openssl but I dont know
> what the encrypt command looks like. I do know that the above command
> does decrypt the data successfully though.
> 
> I want to use Python to decrypt this file. I am thinking of using
> cryptodome but am open to suggestions. Here's what i know from the above
> openssl decrypt command.
> 
> - its uses AES cbc 256 mode for the decryption ( -d )
> - it uses base64 to encode the data "AFTER" (-a) the cryptographic operation
> - it does not specify the initialization vector (IV). 
> 
> I am struggling with how to code for this using python. What I suspect
> is my problem is that i dont know how to properly calculate the IV.
> Looking at the openssl documentation they say to see "key derivation" to
> find out how they handle IV when its not specified. I cant track down
> this key derivation information. Any help will be appreciated! 
> ***