Tag Info

New answers tagged

2

While @schroeder's answer addresses the basic process for signature validation, there is an important step missing. The recipient needs to have a copy of your public key, received and/or validated from a trustworthy source, in order to verify your signature. Without a pre-existing trust in your public key, or in a signing authority which has validated your ...


0

The basic concept behind Digital signatures revolves around a key that only one person (or entity) possesses. That's the 'key' to the authenticity process. There are different technical methods, but they tend to work in some variation of this: a message is composed a 'hash' (a compressed snapshot) of the message is made the sender's key is used to encrypt ...


3

It can actually be done. The instructions at atom.smasher.org/gpg/gpg-migrate.txt are now out of date. Try this. As always, make backups, because it's really easy to mess it up. So these are your 'old' keys: $ gpg -K ---------------------------------- sec 2048R/712A2BBD 2013-01-29 uid Test Key 1 ssb ...


2

A flat file, IMHO, requires too much user intervention. Unless you have it under some sort of revision control ... could get unwieldy. I personally like using KeePass, which also has a few ways of doing multi-user syncing. I don't really have pros and cons for you since I don't know what your requirements are. But it seems to me that you've made up ...


3

By sharing passwords, they are already 'compromised', which might be an ok risk for your environment. You know you have to change ALL shared passwords, even the encryption key whenever you lose a member of the team, so there is not going to be a lowered workload by using either method. What you are really talking about then is simply a 'user logistics' ...


1

Yes, you can. At least you can easily recover the KeyID and with that you can recover the public key from a keyserver (if the user ever uploaded it). You can recover the KeyID using pgpdump (locally if you install it or via the website: http://www.pgpdump.net/) For example message you posted is signed by: Sub: issuer key ID(sub 16)(8 bytes) Key ID - ...


3

Yep, I actually can. With GnuPG, for example: gpg --verify file.txt (with the above file) writes, at the end Primary key fingerprint: 402C C0D3 D527 13E3 FB7C 7103 E481 84B5 B056 76B1 OpenPGP.js works too. openpgp.cleartext.readArmored( ['-----BEGIN PGP SIGNED MESSAGE-----', 'Hash: SHA1', '', '', 'I vote YES on this important measure.', '', ...


6

Yes. The format of the signature is defined in RFC 4880. If you decode the base-64 and interpret the data, you will find that the bytes 18-26 are the issuer ID in this case: ID hex: E48184B5B05676B1 which matches the "Long key ID" behind your link. If you convert the ID to base 64, you can find it in the original signature data, because 18 bytes happen to ...


0

Currently, ECC is supported in GnuPG 2.1 beta. You can compile it from source and see for yourself that the following curves are supported: nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1


0

The public key can be distributed arbitrarily without any impact on security. Storing the public keys with the private keys is totally fine – for example OpenPGP is doing the same. At least linux stores its X.509 certificates in subfolder in /etc/ssl – this makes right management a little bit easier; but once you have access to a private key, you know where ...


0

It is so with existing asymmetric algorithms that the private key includes a copy of the public key, or allows its efficient reconstruction. Therefore, where private keys are, public keys are there too. In any case, public keys are public, so we may assume that everybody has them, including potential attackers, and regardless of where you put them in the ...


1

Well the public keys are fine to store there. Thats why they are public. Anyways, you should seperate the private keys and make sure nobody else gets access to them. So probably storing them on another server would be good practice.


3

You trust A and A tells you that K is the key of B. Therefore, you believe that K is the key of B. Of course, this can be extended to indirect chains. For example if you trust the judgement of A, you can specify that you also trust anyone that A trusts. PGP users sometimes also have key signing events. The idea is that you show up and prove your credentials ...


0

The simplest way to explain it is a bit like "6 degrees of separation". The idea with a web of trust is that you verify someone's identity and decide to trust them to trust people for you. So if I verify that Bob's certificate is actually for Bob and I verify that Charlie's certificate is from Charlie, Bob and Charlie can both verify that Dan is in fact ...


0

Basically it's the concept of decentralising trust management: PKI infrastructure relies on a centralised third party to decide which entity is trustworthy and which one is not. For example (PKI): Bob is a nice guy. Everybody loves bob, and really trusts him. When someone knocks on their door, it's okay if Bob sent him - not if Alice sent that person. A ...


2

A hierarchical public key infrastructure is when some Certification Authority (CA) issues certificates to a lot of sub-entities: the CA signs certificates to guarantee the link between an identity and the public key owned by that entity. The PKI is hierarchical in that there are few CA and each CA signs certificates for a lot of people. In a Web of Trust, ...


0

There are two kinds of trust required: trust in the authenticity of others (named signing in OpenPGP) and trust in a kind of "vouching capabilities", so if you trust in signatures somebody else issued (named trust in OpenPGP). A Trust Example A simple example can make these categories clearer: there are some people of certain authority in the free software ...


0

The security of an asymmetric cryptosystem such as RSA (which PGP uses) is not based directly on the length of the public or private key, but rather on the length of the relative prime numbers which are chosen in their construction. The public and private keys are then derived from those two selected relative primes. The security of the algorithm depends ...


0

The length of the private key determines the length of the public key material. The actual public key that you'll see on a keyserver also contains information such as the user IDs on the key (name/email/comment) and signatures on the key. The size (in bits) of the private key is what provides your security factor. There's excellent material that describes ...



Top 50 recent answers are included