Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?
> 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
Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?
comments On Fri, Nov 2, 2018 at 3:09 PM Michael Wojcik wrote: > > From: openssl-users on behalf of > Nicholas Papadonis > > 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 https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup > > 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
Re: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices?
On Sat, 3 Nov 2018 12:28:02 +0500 Марк Коренберг 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: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] a problem connecting to a specific Site ...
Hello, it is a little bitte weird/strange/complicated; On 02.11.2018 23:05, Matt Caswell wrote: On 02/11/2018 21:51, Walter H. wrote: Hello, when I try to connect to https://www.3bg.at/ I get the following error Handshake with SSL server failed: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message but https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at says its ok ... is the problem on my side or on their side? You'll need to give us more information. I can connect to that server using OpenSSL 1.0.2 s_client. What version of OpenSSL are you using? Is this with your own application or from s_client? What ciphersuites have you configured? Any other relevant configuration that we should know about? the mentioned error comes with squid - ssl-bump on; in case I switch it off and have it as normal proxy, then is really suspisious: - an old Firefox (17.0.11esr) has no problems, the Sites is shown and works - an older Google Chrome (the last one f. WinXP, v46) gives: SSL connection error ERR_SSL_PROTOCOL_ERROR - a fork of the latest Pale Moon (Mypal) and an old Palemoon itself (the last one f. WinXP) gives: An error occurred during a connection to www.3bg.at. Peer's certificate has an invalid signature. (Error code: SEC_ERROR_BAD_SIGNATURE) what is this strange? but what does this mean at the mentioned SSLlabs result: Certificate Transparency No when I compare to any other site (e.g. my own with Let's encrypt certificate), I get Certificate Transparency *Yes (certificate)* is this caused on my side or on the other side? Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature -- 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?
Try openssl cms ( as newer alternative to s/mime) пт, 2 нояб. 2018 г. в 23:30, 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 -- Segmentation fault -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
