Asymmetric encryption
Asymmetric Encryption
Asymmetric encryption, also known as public-key cryptography, uses a pair of mathematically linked keys: a public key for encryption and a private key for decryption. This contrasts with symmetric encryption, which uses the same key for both encryption and decryption. Anyone can use the public key to encrypt a message, but only the holder of the corresponding private key can decrypt it, providing a secure way to exchange information without needing to share a secret key beforehand.
SSH keys and GPG keys are both types of asymmetric encryption keys used for different but sometimes overlapping purposes in digital security.
How it works
- Key Generation: Two mathematically related keys are generated: a public key and a private key.
- Encryption: The sender encrypts the message using the recipient’s public key.
- Decryption: Only the recipient, possessing the corresponding private key, can decrypt the message.
Key Features
- Key Distribution: Asymmetric encryption eliminates the need to securely share a secret key beforehand, as the public key can be openly distributed.
- Digital Signatures: Asymmetric encryption can also be used to create digital signatures, where the sender encrypts a hash of the message with their private key. The recipient can then verify the signature using the sender’s public key, confirming both the sender’s identity and the message’s integrity.
Pros:
- Enhanced Security: The use of two separate keys provides a higher level of security, as even if the public key is compromised, the private key remains secure.
- Key Distribution: No need to share secret keys, making it easier to manage encryption for large groups.
Asymmetric Encryption keys
Asymmetric encryption uses a pair of mathematically related keys: a public key and a private key. The public key can be shared with anyone, while the private key must be kept secret. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa.
Public Key
Used to encrypt data or verify digital signatures. It can be freely distributed.
Private Key
Used to decrypt data encrypted with the corresponding public key, or to create digital signatures. It must be kept secret and secure.
Encryption/Decryption
Data is encrypted using the recipient’s public key. Only the recipient’s corresponding private key can decrypt it.
Digital Signatures
A private key is used to create a digital signature, which can be verified using the corresponding public key. This ensures authenticity and integrity.
Key Exchange
Asymmetric encryption is used to securely exchange symmetric encryption keys between parties.
Examples of Asymmetric Encryption Algorithms
RSA, DSA, and Elliptic Curve Cryptography (ECC).
Advantages of Asymmetric Encryption
- Enhanced Security: The separation of public and private keys provides a strong security layer, especially for key exchange and digital signatures.
- Non-Repudiation: Digital signatures, created with private keys, can be verified by anyone with the public key, ensuring the sender cannot deny creating the signature.
- Key Distribution: Public keys can be easily shared, while private keys remain secure, simplifying key management.
Disadvantages of Asymmetric Encryption
- Slower than Symmetric Encryption: Asymmetric algorithms are generally slower than symmetric algorithms.
- Key Length: Asymmetric keys need to be significantly longer than symmetric keys to achieve the same level of security.
Applications
- Secure Communication: Used in TLS/SSL for secure web browsing (HTTPS).
- Digital Signatures: Used in email encryption, document signing, and cryptocurrency transactions.
- Key Exchange: Used to establish secure communication channels for symmetric encryption.
Why would I sign my git commits with a GPG key when I already use an SSH key to authenticate myself when I push?
Source: https://security.stackexchange.com/a/120725
When you authenticate to Github with your SSH key, that authentication doesn’t become part of the repository in any meaningful or lasting way. It causes Github to give you access for the moment, but it doesn’t prove anything to anyone who is not Github.
When you GPG-sign a git tag, that tag is part of the repository, and can be pushed to other copies of the repository. Thus, other people who clone your repository can verify the signed tag, assuming that they have access to your public key and reason to trust it.
While it isn’t necessary to tag and GPG-sign every single commit, it is wise to provide GPG-signed tags at least on each commit that corresponds to a released version of your code. You may wish to do more than that, but that is the bare minimum of responsible behavior, as it provides reasonable assurance that:
- The commit in question really does correspond to the release in question.
- The commit in question (and to the degree that we trust the SHA1 hashes used in git commit history, all of its predecessors) came from the signer (and, if applicable, the signer’s team).
- The commit in question wasn’t tampered with after the signer tagged it.
Note that I said “reasonable assurance”, not “perfect certainty”…there are other things that can go wrong with software integrity. However, providing signed tags at least for official releases is a huge step in the right direction.
What is the difference between PGP keys, SSH keys, and SSL keys?
Source: https://www.reddit.com/r/privacy/comments/mki839/what_is_the_difference_between_pgp_keys_ssh_keys/
GPG keys are used for signing and/or encrypting things. Package releases, emails, software, etc. I can sign an email and if you know my public key, you can verify that is was me who signed it (no matter how you receive it). If I have you public key, I can also encrypt messages that only you can decrypt.
SSH is used by SSH to authenticate you on a remote computer. It’s also used by tools like git when pulling / pushing to authenticate you with the other party.
SSL keys are the keys used by HTTPS servers to authenticate who they are. They’re signed by certificate authorities which are well known and for which your browser (and OS) already bundles a certificate.