[openssl-users] OpenSSL 1.0.2: CVE-2018-5407 PortSmash

2018-11-07 Thread Misaki Miyashita

Hi,

According to the following website:
    https://www.openwall.com/lists/oss-security/2018/11/01/4

OpenSSL <= 1.1.0h is affected.
Does that mean the problem also exist in the OpenSSL 1.0.2 release?

Thank you,

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


Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?

2018-11-07 Thread open...@foocrypt.net
Ditto,

But don’t tell the Australian Government, it’s probably on their back door 
request list…;)



> On 8 Nov 2018, at 01:26, Bear Giles  wrote:
> 
> FWIW I distrust encrypted drives using hardware encryption. This came out 
> just a few days ago: 
> https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html 
> : Flaws 
> in Popular Self-Encrypting SSDs Let Attackers Decrypt Data.
> 
> On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis 
> mailto:nick.papadonis...@gmail.com>> wrote:
> Interesting.  How about this for a start?
> 
> http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg
>  
> 
> http://nickpapadonis.com/images-share/anunnaki1.jpg 
> 
> http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG 
> 
> 
> On Sun, Nov 4, 2018 at 7:21 PM open...@foocrypt.net 
>   > wrote:
> Hi Nick
> 
> Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method 
> 
> 
> Also,
> 
> I will be sourcing public addendum's as addendum's to my submission into the 
> Parliamentary Joint Committee on Intelligence and Security [ 
> https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions
>  
> 
>  ] regarding the committee’s review of the 'Telecommunication and Other 
> Legislation Amendment (Assistance and Access) Bill 2018' after the Melbourne 
> Cup. It will be similar to the open request for the Defence Trade Control Act 
> review performed by the former Inspector General of Intelligence, Dr Vivian 
> Thom.
> 
> https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community
>  
> 
> 
> 
> -- 
> 
> Regards,
> 
> Mark A. Lane   
> 
> Cryptopocalypse NOW 01 04 2016
> 
> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ 
> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 
> 
> 
> Cryptopocalypse NOW is the story behind the trials and tribulations 
> encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption."
> 
> "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening 
> several commonly used Symmetric Open Source Encryption methods so that they 
> are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'.
> 
> "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under export 
> control by the Australian Department of Defence Defence Export Controls 
> Office due to the listing of Cryptology as a ‘Dual Use’ Technology as per the 
> ‘Wassenaar Arrangement’
> 
> A permit from Defence Export Control is expected within the next 2 months as 
> the Australian Signals Directorate is currently assessing the associated 
> application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical 
> Encryption."
> 
> Early releases of "Cryptopocalypse NOW" will be available in the period 
> leading up to June, 2016.
> 
> Limited Edition Collectors versions and Hard Back Editions are available via 
> the store on http://www.foocrypt.net/ 
> 
> © Mark A. Lane 1980 - 2016, All Rights Reserved.
> © FooCrypt 1980 - 2016, All Rights Reserved.
> © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All Rights 
> Reserved.
> © Cryptopocalypse 1980 - 2016, All Rights Reserved.
> 
> 
> 
>> On 5 Nov 2018, at 10:35, Nicholas Papadonis > > wrote:
>> 
>> Comments
>> 
>> On Sat, Nov 3, 2018 at 5:56 PM Bear Giles > > wrote:
>> > I'm considering encrypting a tar archive and optionally a block file 
>> > system (via FUSE) using either utility
>> 
>> Linux has good support for encrypted filesystems. Google LUKS. 
>>  
>> BTW a tar file starts with the name of the first entry. The 'magic numbers' 
>> are at offset 128 or so. However a compressed tar file will start with a 
>> known value since gzip, b2zip, and 7zip?, all start with their magic values.
>> 
>> Does tar placing known data at a certain offset increase the probability 
>> that someone can perform an attack easier?  They may already know the data 
>> to decrypt at that offset and if the encrypted block overlaps, then the 
>> attack is easier.   

Re: [openssl-users] In-place encryption/decryption via the EVP_* APIs

2018-11-07 Thread Terry Chong
Yes it does, thank you Richard!

Regards,
Terry

> On Nov 6, 2018, at 11:12 PM, Richard Levitte  wrote:
> 
> In message 
>  on Tue, 
> 6 Nov 2018 14:46:52 -0800, Terry Chong  said:
> 
>> Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing 
>> I am wondering
>> about is whether I can do in-place encryption, meaning I don't have to pay 
>> the price of an extra
>> memory buffer to store my cipher text and a potential memcpy back to the 
>> source buffer.
>> 
>> I tried that with the EVP_* APIs by essentially passing in the same buffer 
>> to the plaintext and cipher
>> text input pointers, and it seems to work. I am using AES XTS mode, and I 
>> understand that that
>> may not work if I were to use a different mode.
>> 
>> I am wondering if this behavior for AES XTS that allows in-place 
>> encryption/decryption is going to
>> stay?
> 
> test/evp_test.c does a number of tests on all ciphers we have test
> vectors for, including overlapping buffers (i.e. input and output
> buffer are the same).  So that is to say that if that behaviour ever
> stopped working, we would certainly notice.
> 
> Does that help?
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?

2018-11-07 Thread Bear Giles
FWIW I distrust encrypted drives using hardware encryption. This came out
just a few days ago:
https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html: Flaws
in Popular Self-Encrypting SSDs Let Attackers Decrypt Data.

On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis <
nick.papadonis...@gmail.com> wrote:

> Interesting.  How about this for a start?
>
>
> http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg
> http://nickpapadonis.com/images-share/anunnaki1.jpg
>
> http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG
>
> On Sun, Nov 4, 2018 at 7:21 PM open...@foocrypt.net 
> wrote:
>
>> Hi Nick
>>
>> Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method
>>
>> Also,
>>
>> I will be sourcing public addendum's as addendum's to my submission into
>> the Parliamentary Joint Committee on Intelligence and Security [
>> https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions
>> ] regarding the committee’s review of the 'Telecommunication and Other
>> Legislation Amendment (Assistance and Access) Bill 2018' after the
>> Melbourne Cup. It will be similar to the open request for the Defence Trade
>> Control Act review performed by the former Inspector General of
>> Intelligence, Dr Vivian Thom.
>>
>>
>> https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community
>>
>>
>> --
>>
>> Regards,
>>
>> Mark A. Lane
>>
>> Cryptopocalypse NOW 01 04 2016
>>
>> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @
>> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
>>
>> Cryptopocalypse NOW is the story behind the trials and tribulations
>> encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption."
>>
>> "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening
>> several commonly used Symmetric Open Source Encryption methods so that they
>> are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'.
>>
>> "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under
>> export control by the Australian Department of Defence Defence Export
>> Controls Office due to the listing of Cryptology as a ‘Dual Use’ Technology
>> as per the ‘Wassenaar Arrangement’
>>
>> A permit from Defence Export Control is expected within the next 2 months
>> as the Australian Signals Directorate is currently assessing the associated
>> application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical
>> Encryption."
>>
>> Early releases of "Cryptopocalypse NOW" will be available in the period
>> leading up to June, 2016.
>>
>> Limited Edition Collectors versions and Hard Back Editions are available
>> via the store on http://www.foocrypt.net/
>>
>> © Mark A. Lane 1980 - 2016, All Rights Reserved.
>> © FooCrypt 1980 - 2016, All Rights Reserved.
>> © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All
>> Rights Reserved.
>> © Cryptopocalypse 1980 - 2016, All Rights Reserved.
>>
>>
>>
>> On 5 Nov 2018, at 10:35, Nicholas Papadonis 
>> wrote:
>>
>> Comments
>>
>> On Sat, Nov 3, 2018 at 5:56 PM Bear Giles  wrote:
>>
>>> > I'm considering encrypting a tar archive and optionally a block file
>>> system (via FUSE) using either utility
>>>
>>> Linux has good support for encrypted filesystems. Google LUKS.
>>>
>>
>>
>>> BTW a tar file starts with the name of the first entry. The 'magic
>>> numbers' are at offset 128 or so. However a compressed tar file will start
>>> with a known value since gzip, b2zip, and 7zip?, all start with their magic
>>> values.
>>>
>>
>> Does tar placing known data at a certain offset increase the probability
>> that someone can perform an attack easier?  They may already know the data
>> to decrypt at that offset and if the encrypted block overlaps, then the
>> attack is easier.
>>
>> Thanks
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users