We're trying to troubleshoot a situation where some files sent to us can be successfully decrypted on the command line using GPG but not in a GUI program that interfaces with that library. The error reported by the GUI program is "the key is not marked for encryption". What does it mean for a key to be "marked" for encryption? When is that marking done? When the key is first created, or later, when the key is used to encrypt a file?
Related
I want to host my documentation on ReadTheDoc because.... it's great.
Problem my repository use Google Earth Engine as a dependancy. This lib require a manual authentification or an authentification through a private key.
Is it possible to use private key in ReadTheDoc ? (in Json or string format)
In the RTD administration panel of your repository go to "Environment Variables". there you will be able to add as many env keys as you fancy.
note that once set, the key will not be publicly displayed to you or any other maintainer for security reasons obviously
Troubleshooting
As referenced in this issue if your key is bigger than 2048 characters, it will not be managed by RDT. In this case encrypt your key in a file inside your repository and add the decoding key as an environment variable in RDT.
I am building my Jekyll site with Algolia search.
The documentation about jekyll-algolia says the admin key must be provided in the environment variable ALGOLIA_API_KEY.
However, another page about API key security says
Your admin API key is the most sensitive key: it provides full control of all your indices and data. The admin API key should always be kept secure. Do NOT release it to anybody or do NOT use it in any application, and always create a new key that will be more restrictive. This API key should almost exclusively be used to generate other - more limited - API Keys that will then be used to search and perform indexing operations.
Reading the second page, I'm trying to create a more restrictive key for use with jekyll-algolia in CI builds of my Jekyll website:
However I still get complaints from bundle exec jekyll algolia:
ibug#ubuntu:~/iBug.github.io$ ALGOLIA_API_KEY="0123456789abcdef0123456789abcdef" bundle exec jekyll algolia
Configuration file: /home/wsl/iBug.github.io/_config.yml
Processing site...
AutoPages: Disabled/Not configured in site.config.
Pagination: Complete, processed 1 pagination page(s)
Jekyll Feed: Generating feed for posts
GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
Extracting records...
Updating records in index iBug_website...
Records to delete: 428
Records to add: 420
[✗ Error] Invalid credentials
The jekyll-algolia plugin could not connect to your application ID using the
API key your provided.
Make sure your API key has access to your 14DZKASAEJ application.
You can find your API key in your Algolia dashboard here:
https://www.algolia.com/licensing
ibug#ubuntu:~/iBug.github.io$ echo $?
1
How should I do that? Or must I provide the admin key in CI environments?
Minimum API key ACLs required to allow indexing with jekyll-algolia are deleteIndex, addObject, deleteObject and 'editSettings`.
If one of those ACLs is not set you get an error like this :
[jekyll-algolia] Error:
403: Cannot PUT to
https://APP_ID.algolia.net/1/indexes/your_folder/settings:
{"message":"Method not allowed with this API key","status":403} (403)
In your case, the error message indicates that your application ID is not connected with the API_KEY you provide.
Check your application ID in your Algolia dashboard, and verify that you have a correct algolia.application_id entry in your _config.yml.
If you provide the right application_id and one of her API key, it must work, otherwise it's an Algolia problem.
When configuring and installing an EOS blockchain, you're required to use the "eosio" account as the block producing account or blocks aren't signed. I haven't been able to find much info. however about this pseudo account as it appears to come w/the software by default.
From EOSIO documentation, the "eosio" account is an authorizing account, used to bootstrap EOSIO nodes. But is it stored someplace, or just the default "root" account for EOS blockchains?
You even use this account to create new accounts.
My question is, where is its private key? Is this the key set in the genesis.json file? Can I use another account to configure my blockchain? I would imagine so b/c you specify it at the cmd. line, otherwise the parameter wouldn't be needed.
I'm just frustrated by the lack of documentation surrounding EOS and kindly request help from the community.
UPDATE: 7/13/2018
I changed the "producer-name" to another value but then the blockchain doesn't sign transactions and it sits idle. This is why I'm confused about "eosio." Its key is configured in the config.ini but it doesn't appear that you can change the "producer-name," which is fine, but then why have a "-p" cmd. line parameter? It's just not making sense to me.
its private key is stored at config.ini
# Tuple of [public key, WIF private key] (may specify multiple times) (eosio::producer_plugin)
private-key = ["EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
The second value is the private key.
In addition I think that you can use another account to configure your blockchain . EOSIO is just the testing account .
So i suppose that you can use another block producer if you use another producer name and account with different keys at config.ini
Check this : https://medium.com/coinmonks/test-4fbd38fdc4e8 chapter 4
I'm trying to create a small script where I am able to use google's "OAuth 2.0 for Server to Server Applications" with Tcl. After setting up my service account and making a private key in the format of JSON, I copy and pasted the private key that was within that JSON file. (i.e. screen shot of a part of the private key)
Then I placed the private key within my Tcl script which looks like this:
set keydata "PRIVATEKEY"
set key [::pki::pkcs::parse_key $keydata]
After doing that, I get the following error:
Expected Integer (0x02), but got 30
while executing
"::asn::asnGetBigInteger key ret(n)"
(procedure "::pki::pkcs::parse_key" line 8)
invoked from within
"::pki::pkcs::parse_key $keydata"
("uplevel" body line 45)
invoked from within
I believe I am doing everything correctly. I cannot figure out what I am doing wrong. .
I found that the problem was the key that Google gave me was in PEM format rather than the RSA format that "::pki::pkcs::parse_key" requires. Therefore, I just ran the following to convert my PEM key into RSA format and then ran the code shown above and everything works.
openssl rsa -in domain.key -out domain-rsa.key
I am using RSA cipher for signing the certificate and SSL_CTX_set_tmp_ecdh_callback() api to set the ECDH parameters for key-exchange. The server always ends up choosing TLS_ECDHE_RSA_* cipher suite. If i make the client send only TLS_ECDH_* cipher suites in the clientHello, the server breaks the connection stating "no shared cipher".
Can someone tell me how to make a server choose a ECDH_* cipher over ECDHE_* ?
How is it that the server decides I should choose ECDH_* cipher over ECDHE_* ciphers ?
Now that this is moved where it's ontopic, and clarified enough, and the partying is over:
Ephemeral ECDH suites: TLS suites that use ephemeral ECDH key exchange (ECDHE-*) use at least nominally ephemeral ECDH keys, which OpenSSL calls 'temporary'. OpenSSL through 1.0.2 has 4-6 ways of setting these keys:
SSL_CTX_set_tmp_ecdh or SSL_set_tmp_ecdh set (only) the 'curve' to be used; to be exact this is an EC_GROUP or formally 'parameter set' that consists of an actual curve defined by a curve equation on an underlying field, plus a specified base point which generates a subgroup on the curve of sufficiently high order and low cofactor, but most of the time we ignore this detail and just call it a 'curve'. OpenSSL then generates a random key on that curve for and during each handshake.
SSL_CTX_set_tmp_ecdh_callback or SSL_set_tmp_ecdh_callback sets a function that is called during each handshake and can either set a specific key, or set a curve and OpenSSL generates a random key on that curve.
SSL_CTX_set_ecdh_auto or SSL_set_ecdh_auto new in 1.0.2 causes OpenSSL during each handshake to choose a curve based on the client hello, and generate a random key on that curve.
Note that each ciphersuite using ECDHE also defines the type of key with matching certificate chain the server must use to authenticate: ECDHE-RSA must use an RSA key&cert while ECDHE-ECDSA must use an ECDSA key&cert (or to be precise EC key and ECDSA cert, since the same EC key can be used for ECDSA, ECDH, ECIES, and more, but usually shouldn't). OpenSSL library can be configured with multiple key&cert pairs, one of each type, and commandline s_server can do two static pairs using -cert -key -dcert -dkey plus one for SNI -cert2 -key2, but other programs may or may not.
However, in 1.1.0 these functions are removed and it appears OpenSSL always does what was formerly ecdh_auto.
Static ECDH suites: TLS suites that use static aka fixed ECDH key exchange (ECDH-*) use a static ECDH key and do not use an ephemeral or temporary ECDH key. Since they do not use a temporary key, the functions involved in setting a temporary curve or key are irrelevant and have no useful effect. Instead the static ECDH key must be in the server's configured key and certificate pair, and the certificate must allow ECDH i.e. it must not have keyUsage that excludes keyAgreement. In addition, in TLS 1.0 and 1.1 the configured certificate must be signed by a CA using a signature algorithm matching the ciphersuite: ECDH-ECDSA ciphersuites must use an ECDH cert signed by an ECDSA CA, and ECDH-RSA ciphersuites must use an ECDH cert signed by an RSA CA; see rfc4492 section 5.3. For TLS 1.2 rfc 5246 section 7.4.2 and A.7 for ECC relaxes this requirement and allows the CA cert to be any algorithm permitted by the client's signature_algorithms extension. However on checking I found OpenSSL doesn't implement this relaxation, so part of my earlier comment is wrong; even for 1.2 it requires the CA signature algorithm match the ciphersuite.
In addition for all protocol versions the key and (EE) cert must use a curve supported by the client in supported_curves extension, and the cert must express that key in 'named' form (using an OID to identify the curve rather than explicit parameters) and a point format supported by the client in supported_formats extension. With OpenSSL client this is never an issue because it supports all named curves and point formats, and in practice certificates don't use explicit curve parameters.
Thus to get static ECDH with OpenSSL:
configure the server with an EC key (SSL_[CTX_]use_PrivateKey*) and matching certificate (SSL_[CTX_]use_certificate[_chain]*) that allows keyAgreement and is signed by a CA using RSA or ECDSA -- and like all PK-based ciphersuites also configure any chain certs needed by the client(s) to validate the cert
configure both ends to allow (which is true by default) and at least one end to require or the preference end to prefer ciphersuite(s) using ECDH-xyz where xyz is RSA or ECDSA to match the CA signature on the server cert
ignore ecdh_tmp and ecdh_auto entirely
... except in 1.1.0, which on checking I found no longer implements any static-ECDH or static-DH ciphersuites -- even though the static-DH suites are still in the manpage for ciphers. This is not in the CHANGES file that I can find, and I haven't had time to go through the code yet.
... except in 1.1.0, which on checking I found no longer implements
any static-ECDH or static-DH ciphersuites -- even though the static-DH
suites are still in the manpage for ciphers. This is not in the
CHANGES file that I can find, and I haven't had time to go through the
code yet.
https://github.com/openssl/openssl/commit/ce0c1f2bb2fd296f10a2847844205df0ed95fb8e