Re: [openssl-users] openssl commandline client use
Hi thanks for the responses. I try not to do crypto for the very reasons you raise - i simply don't know enough and your (good) pointed questions have demonstrated that. Context: We are trying for GDPR and other privacy law compliance. We probably need to meet GDPR, US requirements, Australian requirements, Japanese requirements and UK requirements. The data is not hugely critical. It contains names and exercise metrics. It doesn't contain credit card details or anything above the level of names. I don't think it contains addresses but probably does contain names of recognizable organisations which could provide a tuple for identification purposes if the data was compromised. A mysqldump of the db in production at present is around 170Gb however that is text based and we are using a binary solution based on percola xtrabackup so the final size should be smaller for the current time. The documentation on this by the backup software provider is very simplistic and simply pipes the stream of data through openssl and then gzip: mariabackup --user=root --backup --stream=xbstream | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.gz.enc There are thousands of posts that do similar and in non-crypto circles it is the accepted way of doing things. That was my starting point. I am not using a password but generating keys. The symetric key is generated by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is generated by "openssl rand -hex 16". These values are used once and then kept for decryption of that file. They in turn are encrypted before storing - see below. The two keys are held in ram while the backup occurs. They are applied to openssl using the -K and -iv switches. They are then written out to disk. encrypted with a list of public RSA keys and the original deleted from disk. I then package it all up and delete the intervening encrypted files leaving me with an archive with the encrypted backup and several copies of the nonce and key each encrypted by different people's public keys. The backup regime has not been decided as yet. I expect it will be something like a full backup per week and then either incrementals or differentials on the other days. I expect that the fulls will be kept for 30 days and the deltas for 14days. The database backups will sit on a secured server disk which in turn will be backed up by the hosting provider with whatever process and rotation they use. I would expect that headers in the backup stream would be predictable, whether they provide a good enough attack surface I don't know. In addition the clients of course know their data that may also provide an attack surface. Finally I have included an encrypted file with a known plain text phrase. Based on your comments, this will probably not get into production but provides an easy way for testing and debugging to check that things are encrypted or not. The kind of statements that prompted my question was: https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup whose comments suggest that openssl should never be used for production purposes.Their suggestion was GnuPG which isn't suitable for this purpose because it does password/key management that assumes a desktop/laptop environment and manual process. I also looked at ccrypt and mcrypt but then went back to openssl. Cheers Paul On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni wrote: > On Thu, Oct 11, 2018 at 01:23:41AM +, Michael Wojcik wrote: > > > - Data recovery from an encrypted backup is tough. With CBC, one bit goes > > astray and you've lost everything after that. > > No, a 1 bit error in CBC ciphertext breaks only the current block, > and introduces a 1 bit error into the plaintext of the next block. > After that, you're back in sync. > > But yes, indeed "openssl enc" offers little integrity protection. > One should probably break the data into chunks and encrypt and MAC > each chunk with the MAC covering the chunk sequence number, and > whether it is the last chunk. > > -- > Viktor. > -- > 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 commandline client use
On Thu, Oct 11, 2018 at 01:23:41AM +, Michael Wojcik wrote: > - Data recovery from an encrypted backup is tough. With CBC, one bit goes > astray and you've lost everything after that. No, a 1 bit error in CBC ciphertext breaks only the current block, and introduces a 1 bit error into the plaintext of the next block. After that, you're back in sync. But yes, indeed "openssl enc" offers little integrity protection. One should probably break the data into chunks and encrypt and MAC each chunk with the MAC covering the chunk sequence number, and whether it is the last chunk. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl commandline client use
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Paul Chubb > Sent: Wednesday, October 10, 2018 19:16 > I am in the process of using the openssl suite for many things including > encrypting private information. There is a heap of information on the internet > suggesting using the openssl client for these sort of purposes. However in a > very few > places there are also statements that the client is only for testing the > library and > shouldn't be used in anger, that it isn't secure or that only certain > protocols are > correctly implemented. ... > I am using aes-256-cbc to encrypt streamed data (a backup). You haven't explained your threat model. If you're encrypting your diary so your kid sister can't read about your crush at school, then sure, use the openssl utility with aes-256-cbc. If the data you're encrypting falls under a regulatory regime with potential stiff legal consequences, like HIPPA or GDPR, then this is a Bad Idea. Here's the thing: Forget, for a moment, the question of whether you should script crypto using the openssl utility. The real issue, to my mind, is that cryptographic systems assembled by non-cryptographers are very often - probably almost often - fatally flawed. And AES is not a cryptosystem; it's a primitive. All the openssl utility is giving you there is a cipher, key length, and combining mode. Some potential problems that are obvious right off the bat: - No integrity protection over the data. You've run into the Moxie Marlinspike Cryptographic Doom Principle right off the bat. - CBC has problems. *All* the block cipher combining modes have problems. Stream ciphers have problems. How are you avoiding those problems? (Note that experienced people make implementation mistakes in this area.) - What are you doing about padding? Do you have predictable plaintext near the beginning? When do you re-key? - How do you generate and manage your keys? Are you practicing good key hygiene? - Data recovery from an encrypted backup is tough. With CBC, one bit goes astray and you've lost everything after that. (Well, you can brute-force a single-bit error, but it's going to be a tiresome exercise unless you automate it. Multi-bit errors will obviously be worse, and combinatorial explosion will bite you quickly.) ECC after encryption would be a good idea here, perhaps with an erasure code. Maybe you're storing to a suitable RAID mode or something; you haven't told us. I can't really suggest alternatives, partly because this isn't an area I pay a lot of attention to, but mostly because you haven't explained your use case. "Data backup" doesn't mean much unless we have some idea of how much data, how often, what sort of data, what it's being backed up to, how sensitive it is, and so forth. Sorry if this sounds overly negative, but in my opinion your question is severely underdetermined, and it sounds like you're potentially open to some rather serious failures. That may not be a concern - again, I don't know what your use case or threat model is. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl commandline client use
Hi, I am in the process of using the openssl suite for many things including encrypting private information. There is a heap of information on the internet suggesting using the openssl client for these sort of purposes. However in a very few places there are also statements that the client is only for testing the library and shouldn't be used in anger, that it isn't secure or that only certain protocols are correctly implemented. There isn't a statement in the documentation about this and we all know the religiosity of some statements on the internet. I am using aes-256-cbc to encrypt streamed data (a backup). I am running OpenSSL 1.1.0g 2 Nov 2017 Any comments would be helpful. many thanks in advance Paul -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL_get_peer_certificate returns NULL in client_cert_cb after upgrade to openssl 1.1.1
Hi there, I have a client can talk with server, where the client certificate is loaded in client_cert_cb based on matching the server side certificate. it works perfectly in openssl 1.1.0h, however it stops working after I upgrade to openssl 1.1.1. In client_cert_cb , when I call SSL_get_peer_certificate, it returns NULL, which is different from openssl 1.1.0h. I do set SSL_VERIFY_PEER on both sides. any thoughts on this? Regards, Dave -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS_verify provides empty output
On 10/10/2018 13:55, RudyAC wrote: Hello, when verifying a signed email with CMS_verify() the verification failed. That is not the main problem. My problem is that the out data is empty. Using the library I got following error: OpenSSL Error code all:<772382878d> OpenSSL Error code lib:<46d> OpenSSL Error code func: <154d> OpenSSL Error code reason: <158d> OpenSSL Error: error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure The mail body is base64 encoded. When verifying the email on console with "openssl cms -verify" there is no message output, only the error message : Verification failure 47883249174256:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278: 47883249174256:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification failure:cms_sd.c:775: Any hints are welcome The general assumption in OpenSSL is that if the signature is invalid, the contents is probably fake,false or invalid, and thus unwanted. This is generally true in cryptography, but for actual e-mail applications it may very well be desired to allow the user to ignore signature verification failures. If so, one could combine allowing the mail software to access the MIME message normally (as if the signature was some unknown MIME part) with a meaningful (human readable) form of the actual error message from verification (there is more than one way the verification can fail, and the desired human response would often differ). 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
[openssl-users] CMS_verify provides empty output
Hello, when verifying a signed email with CMS_verify() the verification failed. That is not the main problem. My problem is that the out data is empty. Using the library I got following error: OpenSSL Error code all:<772382878d> OpenSSL Error code lib:<46d> OpenSSL Error code func: <154d> OpenSSL Error code reason: <158d> OpenSSL Error: error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure The mail body is base64 encoded. When verifying the email on console with "openssl cms -verify" there is no message output, only the error message : Verification failure 47883249174256:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278: 47883249174256:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification failure:cms_sd.c:775: Any hints are welcome Best regards RudyAC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Regarding Full PKI Authentication
Hi All, I came across a term "Full PKI Authentication". Please someone clarify, what the name "Full" suggests here ? Is there any specific "Full PKI" version available ? Anay specific RFC available for "Full" PKI other than the following ? https://tools.ietf.org/html/rfc5280.html I could see something like "SPKI (simple)". Thanks in advance. Regards, Murugesh P. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Wildcard: how are they correct?
Actually, for public CAs, the current standard (the CAB/F Basic Requirements) require (a), (b) or (c), and prohibit (d). The prohibition on (d) is stated indirectly as a prohibition against putting something that isn't the subjects validated public DNS name in CN. In practice, most public CAs use (a) for maximum backward compatibility. It should also be noted that it is a lot less than 20 years since the popular GNU wget utility started looking at subjectAltName. Lesser known tools may have been even slower to implement it. On 10/10/2018 08:54, Kyle Hamilton wrote: If subjectAltName exists, CN= is not evaluated. All the given examples should work. (The only exceptions are validators that haven't been current for more than 20 years.) None of the examples is correct. CN= should not even be included in the certificate. If it is, (d) is the closest to correct, if "hello world" is replaced by something meaningful to the identification or naming of the subject. -Kyle H On Tue, Oct 9, 2018 at 11:18 PM Walter H. wrote: Hello, which of these possibilities is the correct one? (a) CN=*.example.com and subjectAltName = DNS:*.example.com, DNS:example.com (b) CN=example.com and subjectAltName = DNS:example.com, DNS:*.example.com (c) CN=example.com and subjectAltName = DNS:*.example.com, DNS:example.com (d) CN=hello world and subjectAltName = DNS:example.com, DNS:*.example.com Thanks, Walter -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users 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
Re: [openssl-users] Wildcard: how are they correct?
nothing don't need to happen to the kid and I can't pick any one so I just come out side On Wed, Oct 10, 2018, 3:14 AM Dustin Albright wrote: > I come out side on fruit porch the kid and dad's in side like I said I > can't pick I'd how I ended up doing this but I'm here on the porch u diseve > the respece > > On Wed, Oct 10, 2018, 3:02 AM Dustin Albright > wrote: > >> this really wasn't my intention on all this not really sure how I don't >> it eat her >> >> On Wed, Oct 10, 2018, 2:18 AM Walter H. >> wrote: >> >>> Hello, >>> >>> which of these possibilities is the correct one? >>> >>> (a) CN=*.example.com >>> and subjectAltName = DNS:*.example.com, DNS:example.com >>> >>> (b) CN=example.com >>> and subjectAltName = DNS:example.com, DNS:*.example.com >>> >>> (c) CN=example.com >>> and subjectAltName = DNS:*.example.com, DNS:example.com >>> >>> (d) CN=hello world >>> and subjectAltName = DNS:example.com, DNS:*.example.com >>> >>> Thanks, >>> Walter >>> >>> -- >>> 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] Wildcard: how are they correct?
I come out side on fruit porch the kid and dad's in side like I said I can't pick I'd how I ended up doing this but I'm here on the porch u diseve the respece On Wed, Oct 10, 2018, 3:02 AM Dustin Albright wrote: > this really wasn't my intention on all this not really sure how I don't > it eat her > > On Wed, Oct 10, 2018, 2:18 AM Walter H. > wrote: > >> Hello, >> >> which of these possibilities is the correct one? >> >> (a) CN=*.example.com >> and subjectAltName = DNS:*.example.com, DNS:example.com >> >> (b) CN=example.com >> and subjectAltName = DNS:example.com, DNS:*.example.com >> >> (c) CN=example.com >> and subjectAltName = DNS:*.example.com, DNS:example.com >> >> (d) CN=hello world >> and subjectAltName = DNS:example.com, DNS:*.example.com >> >> Thanks, >> Walter >> >> -- >> 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] Wildcard: how are they correct?
this really wasn't my intention on all this not really sure how I don't it eat her On Wed, Oct 10, 2018, 2:18 AM Walter H. wrote: > Hello, > > which of these possibilities is the correct one? > > (a) CN=*.example.com > and subjectAltName = DNS:*.example.com, DNS:example.com > > (b) CN=example.com > and subjectAltName = DNS:example.com, DNS:*.example.com > > (c) CN=example.com > and subjectAltName = DNS:*.example.com, DNS:example.com > > (d) CN=hello world > and subjectAltName = DNS:example.com, DNS:*.example.com > > Thanks, > Walter > > -- > 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] Wildcard: how are they correct?
if u would like to talk I will come talk with u because u divers the respect On Wed, Oct 10, 2018, 2:18 AM Walter H. wrote: > Hello, > > which of these possibilities is the correct one? > > (a) CN=*.example.com > and subjectAltName = DNS:*.example.com, DNS:example.com > > (b) CN=example.com > and subjectAltName = DNS:example.com, DNS:*.example.com > > (c) CN=example.com > and subjectAltName = DNS:*.example.com, DNS:example.com > > (d) CN=hello world > and subjectAltName = DNS:example.com, DNS:*.example.com > > Thanks, > Walter > > -- > 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
