OpenSSL vs GPG for encrypting files? Security best practices?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL vs GPG for encrypting files? Security best practices?

Nicholas Papadonis
Security Experts,

I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility.  Does anyone have comments on the best practices and tools for either?

I read that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector and it's CLI interface should not be use directly for production.  I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.  I have followed through with the OpenSSL CLI AES tests and am curious where the malleable attack is (in the pipe?).  I am also curious to why GPG, which is an asymmetric key manager, is used for file based encryption when only a single key is required.  How does GPG solve this malleable attack vector.

A security expert's guidance here is much appreciated.

Thank you,
Nicholas



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
> From: openssl-users <[hidden email]> on behalf of Nicholas Papadonis <[hidden email]>
> Sent: Friday, November 2, 2018 14:29

> I read

Where? It's hard for us to determine the quality of your source, or your interpretation of it, if we don't know what it is.

> that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector

I don't know what "malleable attack vector" is supposed to mean in this context. CBC, regardless of the cipher, has certain well-known vulnerabilities. Those probably aren't a concern for most personal file-encryption use cases.

If you have regulatory/legal requirements, then rolling your own data-protection solution, even using presumed-good crypto implementations, is a Bad Idea.

> and [its] CLI interface should not be use directly for production.

I would certainly be leery of doing so. It's not what the openssl utility is primarily intended or designed for.

There are at least two main drawbacks of using the openssl utility in production:

- It primarily exposes primitives, not complete cryptosystems. That means either you're composing those primitives into a complete cryptosystem yourself, which is a process fraught with danger; or you're using an incomplete cryptosystem. In this case, if you use openssl, where is your integrity protection coming from, for example? How are you handling key management, hygiene, and disaster recovery?

- Usability is minimal (for good reason - it's meant as an ad hoc toolkit). There's no error logging or auditing, and minimal diagnostics. Failure modes are pretty much "write an error message and give up".

> I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.  ...
> I am also curious to why GPG, which is an asymmetric key manager,

GPG is an implementation of the OpenPGP standard, plus additional functionality. It's much more than a "key manager".

> is used for file based encryption when only a single key is required. 

GPG supports symmetric encryption. A web search should turn up thousands of pages describing that feature. (Some will be out of date regarding the default cipher and other details; consult the documentation for the current GPG version. I think the default now might be AES-128 CBC, with SHA1 as the MDC, but I haven't checked.)

> How does GPG solve this malleable  attack vector.

Hard to say without knowing what the "malleable attack vector" is.

GPG *is* intended to provide a complete, if rather minimal, cryptosystem for this use case (symmetric encryption of individual files, under a personal-use threat model). For one thing, it (by default) includes an MDC for integrity validation; for another, it provides slightly more sophisticated features for key hygiene.

We don't really know the parameters of your use case, so it's not really possible to make a reasonable recommendation. Do you have regulatory or statutory requirements, or requirements imposed by some other authority (e.g. an employer)? How sensitive is the data? How are you managing your key? What provisions do you need to make for disaster recovery? How are you addressing file integrity? What does your threat model look like?

This is why the simplest approach is to find a complete system that addresses all your requirements. It may not be free, but then neither is your time and energy - you can pay money, or you can pay in opportunity costs and cognitive load. Of course, many people simply ignore the issues and roll their own systems. Often they'll get away with it. Sometimes it will come back to bite them.

--
Micahel Wojcik
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Hanno Böck-4
In reply to this post by Nicholas Papadonis
Hi,

Malleability means that an attacker who is able to modify your
encrypted data can - given some partial knowledge about the plaintext -
do some modification of the ciphertext that will lead to specific
modifications in the plaintext.

This can e.g. mean that if the attacker knows your plaintext is a tar
file he knows the first bytes. Thus by some clever XOR-ing he can
inject blocks into your ciphertext that he can control.

All of this was the basis of the efail attack earlier this year.

Ideally you don't want to use any cipher that is vulnerable to these
kinds of attacks. More modern cipher modes use authenticated
encryption, which means they'll detect if modifications have happened.
Such modes are e.g. GCM or Poly1305.

As for OpenSSL CLI vs. GnuPG, neither of them is ideal, but GnuPG is
better. It uses a hash to provide some kind of authentication. It's not
really an authenticated encryption mode, but it comes close.

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Марк Коренберг
In reply to this post by Nicholas Papadonis
Try openssl cms ( as newer alternative to s/mime)
пт, 2 нояб. 2018 г. в 23:30, Nicholas Papadonis <[hidden email]>:

>
> Security Experts,
>
> I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility.  Does anyone have comments on the best practices and tools for either?
>
> I read that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector and it's CLI interface should not be use directly for production.  I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.  I have followed through with the OpenSSL CLI AES tests and am curious where the malleable attack is (in the pipe?).  I am also curious to why GPG, which is an asymmetric key manager, is used for file based encryption when only a single key is required.  How does GPG solve this malleable attack vector.
>
> A security expert's guidance here is much appreciated.
>
> Thank you,
> Nicholas
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



--
Segmentation fault
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Hanno Böck-4
On Sat, 3 Nov 2018 12:28:02 +0500
Марк Коренберг <[hidden email]> wrote:

> Try openssl cms ( as newer alternative to s/mime)

cms is not newer than s/mime, it's the underlying message format of
s/mime.

According to this
https://www.openssl.org/docs/man1.0.2/apps/openssl.html
it only supports deprecated cipher modes (cbc, cfb, ofb, ecb) and has
exactly the malleability vulnerability the original poster was asking
about (including a wide variety of obscure and some insecure ciphers). I
don't think this should be recommended.

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Nicholas Papadonis
In reply to this post by Michael Wojcik
comments
On Fri, Nov 2, 2018 at 3:09 PM Michael Wojcik <[hidden email]> wrote:
> From: openssl-users <[hidden email]> on behalf of Nicholas Papadonis <[hidden email]>
> Sent: Friday, November 2, 2018 14:29

> I read

Where? It's hard for us to determine the quality of your source, or your interpretation of it, if we don't know what it is.


On stackexchange

 
> that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector

I don't know what "malleable attack vector" is supposed to mean in this context. CBC, regardless of the cipher, has certain well-known vulnerabilities. Those probably aren't a concern for most personal file-encryption use cases.

If you have regulatory/legal requirements, then rolling your own data-protection solution, even using presumed-good crypto implementations, is a Bad Idea.

> and [its] CLI interface should not be use directly for production.

I would certainly be leery of doing so. It's not what the openssl utility is primarily intended or designed for.

There are at least two main drawbacks of using the openssl utility in production:

- It primarily exposes primitives, not complete cryptosystems. That means either you're composing those primitives into a complete cryptosystem yourself, which is a process fraught with danger; or you're using an incomplete cryptosystem. In this case, if you use openssl, where is your integrity protection coming from, for example? How are you handling key management, hygiene, and disaster recovery?

- Usability is minimal (for good reason - it's meant as an ad hoc toolkit). There's no error logging or auditing, and minimal diagnostics. Failure modes are pretty much "write an error message and give up".

> I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.  ...
> I am also curious to why GPG, which is an asymmetric key manager,

GPG is an implementation of the OpenPGP standard, plus additional functionality. It's much more than a "key manager".

> is used for file based encryption when only a single key is required. 

GPG supports symmetric encryption. A web search should turn up thousands of pages describing that feature. (Some will be out of date regarding the default cipher and other details; consult the documentation for the current GPG version. I think the default now might be AES-128 CBC, with SHA1 as the MDC, but I haven't checked.) 
 
> How does GPG solve this malleable  attack vector.

Hard to say without knowing what the "malleable attack vector" is.

GPG *is* intended to provide a complete, if rather minimal, cryptosystem for this use case (symmetric encryption of individual files, under a personal-use threat model). For one thing, it (by default) includes an MDC for integrity validation; for another, it provides slightly more sophisticated features for key hygiene.

We don't really know the parameters of your use case, so it's not really possible to make a reasonable recommendation. Do you have regulatory or statutory requirements, or requirements imposed by some other authority (e.g. an employer)? How sensitive is the data? How are you managing your key? What provisions do you need to make for disaster recovery? How are you addressing file integrity? What does your threat model look like?
No regulatory requirements.  I'm a personal user making sure to take best practices into account for securing data.  I also have the assumption that there are numerous attack vectors in involved in storing computer data, all the way back to the design and manufacturing process.  I.e. you need to design, manufacture and test your own computer to be truly secure.

I want to keep at least two copies of data in different locations for disaster recovery.  Each copy itself should have a backup stored with it in case of a bit error.

This is why the simplest approach is to find a complete system that addresses all your requirements. It may not be free, but then neither is your time and energy - you can pay money, or you can pay in opportunity costs and cognitive load. Of course, many people simply ignore the issues and roll their own systems. Often they'll get away with it. Sometimes it will come back to bite them.

Thanks Micahel!

Nicholas 
--
Micahel Wojcik
--
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
Reply | Threaded
Open this post in threaded view
|

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

Bear Giles
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. Most (all?) distros allow you to install on an encrypted filesystem and with a little bit of research you can have encrypted external drives and thumb drives. If you dig into /etc/crypttab and udevadm you can even have encrypted drives automount as long as LUKS already has your passphrase. (E.g., I'm a bad bear because I used the same passphrase on my laptop and my thumb drives.) It's not limited to passphrases - you could use a hardware device like digikey or a file containing the secret key.

I am also curious to why GPG is used for file based encryption when only a single key is required. 

As I recall PGP always uses a random session key* for the actual encryption. with N copies of the key encrypted using a PBE passphrase, a public key in the keyring, etc. That's how multiple people can decrypt a file even though they don't share any keys. The data itself is chunked into blocks and each block uses the same key but a different random salt.

I don't recall if also it prepends or appends random data. That's a common counter to known-text attacks like knowing that a zip file always starts with the same few bytes. 

(* Well, "session key" when it's data-in-flight. I don't remember the term when it's data-at-rest.)

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.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Nicholas Papadonis
Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

FooCrypt
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.



-- 

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 <[hidden email]> wrote:

Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
In reply to this post by Nicholas Papadonis
> From: openssl-users [mailto:[hidden email]] On Behalf Of Nicholas Papadonis
> Sent: Saturday, November 03, 2018 13:03

> https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup

Thanks. Yes, that's talking about the CBC mode malleability issue, which Hanno Boeck described.

I didn't want to assume you were referring to CBC malleability, because your original email implied you were talking about an issue specific to OpenSSL and referred to a pipeline at one point. Making assumptions that discard conflicting information can be dangerous when discussing security-related matters. (CBC malleability applies to all use of CBC mode, regardless of implementation or underlying block cipher. A cryptosystem using CBC has to provide some kind of message integrity to prevent it.)

> No regulatory requirements.  I'm a personal user making sure to take best practices into account for
> securing data.  I also have the assumption that there are numerous attack vectors in involved in storing
> computer data, all the way back to the design and manufacturing process.  I.e. you need to design,
> manufacture and test your own computer to be truly secure.

As with standards, the great thing about "best practices" is there are so many sets to choose from.

Here's the thing: There is no such thing as "truly secure". Security is not an absolute state. There are various ways to model it, but it's always in some sense economic. You can look at the relative costs of attack and defense, and the value of the protected system to the attacker and the defender; you want to maximize the cost of attack, preferably so that it makes access unprofitable, while keeping the cost of defense within an appropriate budget. (Note that "cost of defense" includes things like usability for authorized users and risk of data loss if a key or ciphertext is corrupted; it's not just material and effort.) You can also model security in terms of the probability of various types of adverse events (unauthorized data exposure, alteration, or loss, in this case) and the costs to you of those events - you want to minimize the sum of the probability-cost products.

Understanding security as relative rather than absolute also means that "best practices" will depend on your threat model and security budget.

Now, all that said: In this particular case, if you're weighing using the openssl command-line utility or gpg, use gpg (in symmetric-encryption mode). For the reasons Hanno and I mentioned here on openssl-users, and the reasons given in that StackExchange thread. The openssl utility isn't intended for this; gpg is.

Some people have suggested some other alternatives, such as encrypted filesystems. There are also inexpensive encrypting USB drives and the like, which are good for some use cases.

> I want to keep at least two copies of data in different locations for disaster recovery.  Each copy itself should
> have a backup stored with it in case of a bit error.

OK. It's good to consider and mitigate various failure modes.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
In reply to this post by Hanno Böck-4
On 03/11/2018 10:11, Hanno Böck wrote:

> On Sat, 3 Nov 2018 12:28:02 +0500
> Марк Коренберг <[hidden email]> wrote:
>
>> Try openssl cms ( as newer alternative to s/mime)
> cms is not newer than s/mime, it's the underlying message format of
> s/mime.
>
> According to this
> https://www.openssl.org/docs/man1.0.2/apps/openssl.html
> it only supports deprecated cipher modes (cbc, cfb, ofb, ecb) and has
> exactly the malleability vulnerability the original poster was asking
> about (including a wide variety of obscure and some insecure ciphers). I
> don't think this should be recommended.
>
For clarity, the "openssl smime" and "openssl cms" commands to
provide mostly complete cryptosystems and are used as the
S/MIME implementation for some respected e-mail clients that
also use the gpg command line for OpenPGP messages.

Also the "openssl smime" command (and underlying OpenSSL API)
has from time to time been described as superseded by the
"openssl cms" command (and API), though there are holes in the
backward compatibility.

Now the S/MIME and CMS encryption standard may suffer from lack
of integrity checks when not carefully combined with the signing
feature of that same crypto system.

There are other subcommands of the openssl command line utility
which are similarly respected high level operations rather than
the low level primitive operations also available such as "enc".

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
Reply | Threaded
Open this post in threaded view
|

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

Nicholas Papadonis
In reply to this post by FooCrypt

On Sun, Nov 4, 2018 at 7:21 PM [hidden email] <[hidden email]> 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.



-- 

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 <[hidden email]> wrote:

Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> wrote:

On Sun, Nov 4, 2018 at 7:21 PM [hidden email] <[hidden email]> 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.



-- 

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 <[hidden email]> wrote:

Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

FooCrypt
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 <[hidden email]> 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 <[hidden email]> wrote:

On Sun, Nov 4, 2018 at 7:21 PM [hidden email] <[hidden email]> 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.



-- 

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 <[hidden email]> wrote:

Comments

On Sat, Nov 3, 2018 at 5:56 PM Bear Giles <[hidden email]> 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