Re: OpenSSL vs GPG for encrypting files? Security best practices?

["openssl@xxxxxxxxxxxx" <openssl@xxxxxxxxxxxx>]

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 <bgiles@xxxxxxxxxxxxxx> 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 <nick.papadonis.ml@xxxxxxxxx> 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 openssl@xxxxxxxxxxxx <openssl@xxxxxxxxxxxx> 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 <nick.papadonis.ml@xxxxxxxxx> wrote:

Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <bgiles@xxxxxxxxxxxxxx> 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