In general, one key per identity should be fine.
One key can include:
Several UIDs (for separate mail addresses, ...)
Several subkeys (for different devices, so you can put some subkey on your mobile; if it gets lost, revoke only this)
Less hassle when signing keys, interacting with keyservers, cross-signing your keys
Less hassle maintaining ...
tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.
The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.
For subkeys, the effect is rather simple: after a given time frame, the ...
Notably, PGP is not the problem. The problem lies with the mail handling apps in your browser which you have allowed to use your PGP keys. Those browser apps decrypt the message as they should, but inside that message in addition to your secret is a trojan URL which is an attackers site. Your browser app stupidly tried to connect to the URL which has your ...
GitHub itself is signing commits made through the online editor using the key 0x4AEE18F83AFDEB23:
GitHub will automatically sign commits you make using the GitHub web interface. These commits will have a verified status on GitHub. You can verify the signature locally using the public key available at https:/...
How many keys are okay? How many are too much?
You only need multiple keys if you want to have multiple disconnected identities. Identities are signed and a key may have multiple identities on it. Thus, you could have one key with all the identities that you wish to lay claim to.
Equally, you can create as many keys as you want to have disconnected ...
Apart from the fact you'd better not deploy custom crypto code anyway, you're reinventing the wheel. OpenPGP's string-to-key functionality is configurable and can be adjusted to your needs, while not losing compatiblity. I'm not discussing your choices in the number of cycles here, although they seem a little bit harsh. I'd recommend reading At what point ...
You can set every key to ultimate trust through opening the key edit command line
gpg --edit-key [key-id]
and running the trust command. You will now be prompted to select the trust level:
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I ...
There are different classes of certifications. Quoting RFC 4880, OpenPGP, 5.2.1. Signature Types:
0x10: Generic certification of a User ID and Public-Key packet.
The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the owner
of the key is in fact the ...
Disable HTML rendering. (Not HTML sending: HTML rendering. It doesn't matter what mail you send; what matters is what your mailer does on receipt of the adversary's mail.)
Consider configuring your mailer to disable automatic PGP key download, S/MIME OCSP verification, S/MIME CRL download, S/MIME intermediate CA download; consider periodically updating ...
OpenPGP always applies hybrid encryption (no matter how small the file/message is), thus encrypts the message using symmetric encryption and a session key, which again is encrypted using one or more public keys and asymmetric cryptography (once for each recipient). In fact, also symmetric encryption might be used again for the session key, if you also add a ...
What is the most and least secure way of going about encrypting emails?
There is no difference in security: both use the same cryptographic principles, they just use another method of embedding OpenPGP into e-mails.
I am looking for security and have no idea which to use, though I do know HTML will not work with PGP Inline but will with PGP/MIME.
First of all, you don't need to enter them, or you can enter false ones if you like, so go ahead and do so if you so prefer. (You may need to read up on the options to disable the fields.)
But the reason PGP asks for such information is that it's not just a tool for encrypting messages—it's also a tool for defeating impersonation, i.e., proving that ...
OpenPGP Includes Key Management
From the introduction to RFC 4880, OpenPGP (highlighting added be me):
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage. These services include
confidentiality, key management, authentication, and ...
There is another solution apart from disabling HTML rendering - which you nonetheless should.
This is a list of affected clients and webmailers1:
The efail attack in its current form relies first and foremost on a client vulnerability. If you are using one of the affected clients, you might want to think about changing to another one for the time being, ...
If you already have an SC and E keys, and you want to remove your C ("master") key to offline storage, then all you require is a new S key (SSK1 in your example). You do not need to create a new encryption subkey -- your existing one is just fine for this purpose.
I then change password using gpg --edit-key $id passwd. According to some guides it should ...
Checking a key is signed
The short answer is that you use the command gpg --list-sig <key id>.
For example, I went to the site you listed above and downloaded the qubes release 2 signing key. I then imported that key into my local gpg keyring:
$ gpg --import qubes-release-2-signing-key.asc
which results in the following
pub rsa4096/0A40E458 ...
Note that an expiration date on the master key doesn't really do anything for security, as anyone who compromised that could always just extend it anyway. See http://madduck.net/blog/2006.06.20:expiring-gpg/.
(Expiring subkeys, on the other hand, can be useful, and the option at key creation sets the date on all of the keys.)
No, the Yubikey 4 is not Open Source:
The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited ...
OpenPGP does not really use an initialization vector (it is defined to be all-zero). Instead, it uses a block of random data afterwards, which takes the role of the initialization vector in the OpenPGP-specific OpenPGP CFB mode.
From RFC 4880, OpenPGP, 13.9. OpenPGP CFB Mode:
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
Trying to clarify some of the details from Jens Erat's post in human language:
" " => 0x00 Generic certification: does not make any particular ownership assertion
"1" => 0x11 Persona certification: has not done any ownership verification
"2" => 0x12 Casual certification: has done some identity verification
"3" => 0x13 Positive certification: ...
Is this passphrase-protected? There's a high probability it is!
How can I know if this is passphrase-protected?
Simply enough: import the exported key and try to use it; if it was originally created with a passphrase, it will be exported with the passphrase. You need to know it after the import, too.
It is possible to create a passphrase-less key pair, ...
Pictures would add additional information on your identity: similar to providing information on your name, location, place and date of birth, they might help others in identifying you (and distinguishing from people with similar names). A picture of you (and your signature, which seems an interesting idea) might help at verifying people meet with the right ...
OpenPGP Key IDs
OpenPGP key IDs (and fingerprints) are used to reference keys when performing several actions like requesting and sending keys, or when verifying ownership. For example, you'd exchange the fingerprint with the key's owner on a separate, trusted channel to make sure the key really belongs to the person that claims to own the key.
The OpenPGP ...
I work at Mailfence as an Information security analyst.
Where do they store my key.
When you generate your keypair, we first encrypt it with your passphrase in the browser and then store it on our servers. This way, server never sees the key in plain-text, and a zero-knowledge framework gets established.
If my private key is stored on their servers, ...
The most common case I've seen so far is to sign the key and then send the signed key (well, just the single signature) via e-mail to the purported e-mail address. If there's more than one e-mail address on a key, to each address you only send the signature for this address, encrypted with their public key. Do not upload the signature to a key server or make ...
You did nothing wrong. The signature is correct, but GnuPG could not verify the key's validity, thus the signature is not deemed valid. With other words, GnuPG explains you that while the signature is issued by a totally valid key, the key could have issued by anybody (you can create keys for arbitrary mail addresses, there is no central instance verifying ...
nor is communicating with people who are willing to use GPG
PGP/GPG or S/MIME provide end to end encryption and tamper resistance. But to offer this it needs to be used by both ends of the communication. If the other end is unwilling to use PGP or S/MIME then no end to end encryption is possible. This is the same with HTTPS: if the web server does not offer ...
I am trying to create a secured policy for storing and maintaining keys between users of my company.
The following answer is based on those requirements I assume based on your post (I'll call your users employees in the following):
You need to be able to revoke employee keys.
You want to be able to decrypt information encrypted for employee.
In cryptography, signing and encrypting are orthogonal.
Encrypting data provides confidentiality: (ideally) only the intended recipient will be able to gain access to the plaintext. Modern message encryption systems are generally designed to be non-malleable, meaning that it is very difficult to change a message. That said, an adversary which is able to ...