This will mean a lot of unneeded overhead. I'd suggest following:
Since you don't have certificates issued by CA, create your own CA. Namely, create a self-signed certificate and add it to a key store on both servers, so that your certificate is trusted.
Issue certificates to each server and sign them with private key of your own CA.
Make your servers use ...
All android 7+ devices are equipped with Trusted Execution Environment (TEE) as a mandatory requirement for Google apps licensing. It's a hardware backed keystore which provides isolated storage and data processing for cryptographic blobs. In Qualcomm Snapdragon and Samsung Exynos SoCs, TEE is based on ARM Trustzone. Some devices like in Pixel and iPhone ...
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
The end of section 3.2 states:
This specification covers two classes of certificates: CA certificates
and end entity certificates. CA certificates may be further divided
into three classes: cross-certificates, self-issued certificates, and
Is identity certificate same as public key?
No, a certificate contains a public key but is not the public key itself.
If no, then is identity cert considered a secret?
Usually not, it usually contains only information not considered secret.
How are they related?
A certificate is the public key of an identity together with more information about the ...
No, I don't think that the solution is good. Let’s go through it:
This is fine
If we can manually copy, why not copy the public keys directly?
Here's the real problem. As this is done on an insecure connection, you can't be sure that the first server actually talks to the second server.
You weren't specific on how the exchange works, but using the token ...
Steffen Ullrich gave a good answer.
I would just add a few more points.
The main idea of certificate is that there is some party (called CA - Certification Authority) that is trusted by all PKI participants, which confirms the ownership of the public key. You can interpret certificate as statement: "We, the CA, confirm, that this public key belongs to ...
I generally agree with Steffen Ulrich, I just want to add few cents, since OP references my own answer which I consider proper and valid.
However OSCP responses are also signed by a revocable entity
it's not a revocable entity. OCSP Signing certificates include id-pkix-ocsp-nocheck certificate extension that instructs clients to not check this particular ...
If you renew (same key, same name) the Root CA certificate then the leaf certificates will still validate. A certificate's identity is defined by its key and name, and if neither change then it's effectively the same certificate. All a renewal does is change the validity period of the original certificate.
Contrast the above with a re-key (new key, same ...
... chicken-and-egg problem ...
There is no real chicken-and-egg problem. Revocation (no matter if CRL or OCSP or something else) is only one part of the certificate validation, and it can still be better to do 95% (i.e. HTTPS w/o revocation check) than doing 0% (plain HTTP).
... don't provide replay protection ... you cannot reliably issue an emergency ...
You have a couple of options on what to pin. Depending on which one you chose offers you different trade-offs. Here are some typical pins:
Pin the certificate itself
Yes, you will need to change it when the certificate expires. Most secure but quickly causes availability issues if users don't update often enough.
Pin the public key of the certificate
The only way to establish initial trust between two servers separated by an untrusted network has to involve a manual1 step. This can be achieved either by copying it manually or by manually comparing whether the keys are transmitted correctly before trusting them. The manual comparison is typically done using a key fingerprint. It can be done by comparing a ...
TLS Channel binding is targetting to prevent MitM exposure of the both Secret (password) and Data.
SASL-SCRAM itself works in a way that it allows authentication without passing the password - password is used as shared secret to perform cryptographic operations on shared non-secret (nonce). That prevents MitM exposure of credentials however it does not ...
For a Diffie-Hellman key exchange the shared secret created will be the same if the same key pairs are used. This means that if Eve gets hold of a private key of either sender or receiver then they can compute the shared secret and decrypt all past and future messages between Alice and Bob. The common way to get around this problem is to use ephemeral keys ...
The former is correct, as verified by RFC 2986: PKCS #10: Certification Request Syntax Specification:
The process by which a certification request is constructed involves
the following steps:
1. A CertificationRequestInfo value containing a subject
distinguished name, a subject public key, and optionally a
set of attributes ...
The important part is "The probability that a BigInteger returned by this method is composite does not exceed 2e-100"
Hardware isn't perfectly reliable: https://community.hiveeyes.org/t/soft-errors-caused-by-single-event-upsets-seus/1891
Lets make some assumptions:
1 bit flip per day for a machine from cosmic rays
You could assume 1 bit flip per ...
Don't try to learn data security by building a crypto exchange. It's like learning how to make a boat by creating a cruise ship. Or learn Physics starting with Quantum Chromodynamics.
Try a secure file storage first. Or a secure messaging platform. Or a secure emoji election. Simpler things, no financial damage if done wrong, no massive lawsuits, no need to ...
Can the same public key be used with RSA, Elliptic Curve, or other asymmetric encryptions algorithms?
No. The algorithm is inherent in the key.
If not, how is a public key bound to a X.509 Certificate?
It is not bound to the certificate, but it is part of the certificate.
Presumably, you'd have to know the algorithmic choice before determine a public key,...
This is known as a 'known plaintext' attack. All modern encryption algorithms are designed to be resistant to this type of attack.
Many types of files contain known plaintext. For example, PDF documents begin with the header '%PDF'. Other information in most PDF documents is easy to guess, such as embedded fonts, formatting info, etc. If known plaintext ...
With Bob's key and the traffic, could Eve now decrypt all content Bob has ever sent to Alice?
It is about "forward secrecy" and it depends on how Threema manages session keys. (From wikipedia: "Forward secrecy protects past sessions against future compromises of secret keys or passwords.")
There are two points to consider:
This sentence is technically correct, but confusing. The CSR contains the public key. The CA does “create” a public key as an intermediate step in generating the certificate, but all it does is to copy it from the CSR, and then embed it in the certificate.
It's true that the knowledge of the public key doesn't compromise the private key, but the CA never had ...
In most cases, the CA will have issued a cross-signed certificate with a longer expiration date. Most modern web browsers will have the cross-signed certificate in their certificate store, and will chain back to the cross-signed certificate instead of the expired root certificate, if the browser finds that the original root certificate has expired. See ...
I would suggest that this is just base64 encoded PEM:
$ echo "-----BEGIN CERTIFICATE-----" | base64
$ echo "-----BEGIN CERTIFICATE-----" | base64 | cut -c-3
Java 8's BitInteger Class's
largePrime if requested prime has more than SMALL_PRIME_THRESHOLD = 95 bits that calls
searchSieve.retrieve, in which a BitSieve (Sieving) is performed before the costly call of
primeToCertainty (Rabin-Miller Test with 50 rounds), the probabilistic calculation of the Rabin Miller is given by 4-k, so the ...
The private key is never included in the certificate, certificates are publicly available.
The CA key is specified either through a flag or through the config file. When none is specified, the default config file is used (depends on how openssl was built) which points to $dir/private/cakey.pem for the private key (at least mine does, mileage may vary).
You are correct, the Root CA is required when clients connect to the service with client authentication certificates.
Your server may be a client of another service. In that case, it also needs the Root CA in its own trust-anchor store (Trusted Root CA as you called it). Without this, the server couldn't authenticate the signatures on any certificates ...
With OpenSSH it's not possible. As said by @TildalWave you need to use the fork from Roumen Petrov PKIXSSH.
Once you have your X509 certificate you don't need to add the public key on the authorized_keys file.
You need to configure two things in the server side:
Add the certificate for the CA in the directory set by CACertificatePath directive in ...
I'm guessing it's for OCSP.
I've had a look at the CAB forum Baseline Requirements. I did a full text search for digitalSignature and there are only two hits.
Hit 1/2 is for root CAs:
This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign
MUST be set. If the Root CA Private Key is used for ...
I feel your confusion. From your provided link, I copied the first paragraph:
The Web Services Enhancements for Microsoft .NET (WSE) allows a sender, which can either be an XML Web service or its client, to encrypt portions of the SOAP message by using the public key for the recipient's X.509 certificate. A receiver, which can be either a Web service or its ...
If you have access to any trusted HTTPS server, post the public key of every server on it, download on the servers.
If your HTTPS server is properly configured, no MitM can change the public keys, and the servers can download securely the public key of every other server. And if cost is an issue, Let's Encrypt lets you create a public facing SSL certificate ...