New answers tagged

2

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. Employees ...


0

After the public key has been imported pgp --import PublicKeyToImport.asc run pgp --list-userids to determine the key or User ID to be used with --encrypt. Alg Type Size/Type Flags Key ID User ID ---- ---- --------- ------- ---------- -------


3

Where is the PKCS v1.5 or OAEP padding? For RSA, PKCS1v1.5 is in 5.1. The other kind of publickey encryption used by PGP and described in the same section, usually written El Gamal or abbreviated EG but here written Elgamal, is already randomized and doesn't need to pad the encrypted data, which is for either algorithm a slightly modified form of the ...


0

Generally, in terms of security, reusing passwords is not a good idea. Mind that the revocation is not the only problem if you get compromised. An attacker with access to your previously encrypted messages, by having the key and password, is gonna be able to decrypt them. So, having different passwords makes the attacker's job harder. Also, making this ...


0

Contacted Peter Todd directly, this is his response: Basically, you guys are quite right to recognise that this isn't timestamping a PGP signature, but rather weakly proving the signature was created after a certain point in time. But that's a rather weak proof, as what exactly prevents you from recreating the signature with a different blockhash? Not ...


3

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 ...


0

When creating a revocation certificate, GnuPG prints the key's primary/default user ID to help you identify the key. The revocation certificate is not including any user ID, but targets the primary key. You should be able to verify that using gpg --list-packets or pgpdump, you should observe a signature type 0x20 (key revocation), not type 0x30 which is a ...


3

This is a great question, I'm not 100% sure, but my guess is that it's a proof of age that the PGP key is newer than 2013-10-19. My reasoning is as follows: What makes blockchain mining computationally hard is fiddling with the nonce until the hash of that block has a specific number of leading zeros (16 hex zeros, or 64 binary zeros in this case). Once you ...


1

Let me answer this based on how PGP/GPG works. So you have a file for say Client X, and you are using FTP as a delivery mechanism. You want to ensure that your data is protected (encrypted) and only Client X can read it. To do so, you would be using your PGP key for signing, and they will use their key for decrypting. You (PGP key which can be looked up on ...


1

It is possible, if your server accepts files uploaded by an anonymous user and if you don't provide a hash (e.g. SHA-256, SHA-512,...) in order to check that cred.gpg actually contains passwords.pdf and not evilfile.pdf.


2

Risks of Exposing Encrypted Information With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it. Your encrypted information will stay private as long as the crypto works (no flaws in the underlying mathematical principles are found), the ...



Top 50 recent answers are included