# Tag Info

4

What they're doing is doing a fast test to see if a candidate prime prime+step has any of the smallest 669 primes as a factor (by testing whether prime%p + step is a multiple of the small prime p. If they do find that the candidate has a small factor, then it is obviously not prime (and so they don't need to spend the comparatively long time running the ...

4

man gpg... GnuPG may ask you to enter the passphrase for the key. This is required because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol. I guess that answers it. Though if anybody knows more, feel free to share.

3

I think I found an answer in this thread: http://www.gossamer-threads.com/lists/gnupg/users/65236 In short: There is a packet which looks like a key revocation but it could be forged. If an OpenPGP application downloads the key from the server then it does a signature check.

3

TL;DR: There are different possibilities: A timestamp is included before compression, and can result in slightly different compressed message lengths. The encrypted session key is stored as multi-precision integers, which are of dynamic length. Finally, ASCII-armoring adds a padding that might enlarge the size difference slightly. Compression and Timestamps ...

3

This is a really hard question to answer. The definitive answer can only be found in the source code of gpg. However I can still answer your question using a mail I found (from 2013, details may have changed). Is 2 "better" (i.e. more random) than 0? Yes, 2 is "better" than 0 and 1. As per the linked mail the quality level determines the number of ...

3

The only possible answer to this is to check out the OpenPGP format and see if the message adheres to that format. You may need to build in some mechanisms to filter out tiny mistakes or extensions in the message though. As Open PGP is, well, open, there should be plenty libraries that perform this parsing for you. Library recommendations are off topic here ...

3

There are no known-plain-text-attacks known for the symmetric encryption protocols used by OpenPGP with the OpenPGP CFB mode in use, so you can safely rely on it. In the end, the very first few bytes of OpenPGP packets are generally rather easily guessable by design, as they usually introduce a compression-packet and literal (data) packet with either very ...

3

Sounds like a description of ECIES to me. ECIES is a hybrid cryptosystem that builds upon ECDH. Basically: the static public key of the receiver is used together with an ephemeral key pair generated at the sender. The public key of the receiver and ephemeral private key of the sender are used to generate a "shared secret" using ECDH. This shared secret is ...

2

I'm assuming that you mean any time the file changes, it is re-encrypted with PGP. Here is a description of how PGP encryption works: Whenever you change the file and re-encrypt with PGP, a new, independent session key is chosen. So what you end up with is a (potentially only slightly) modified file, being encrypted with a brand new session key. All ...

2

Pub alg - Reserved for Elliptic Curve(pub 18) unknown(pub 18) The output explains pgpdump knows this is an elliptic curve algorithm (which has ID 18), but does not understand the exact details (which curve was used, ...). Try gpg --list-packets instead which has full support for ECC (requires GnuPG 2.1, binary might also be called gpg2 on Debian and ...

2

You cannot encrypt a file with a private key. With RSA, that's not because of any technical obstacle (with other schemes private keys literally are not valid inputs to the encryption function), but because private keys are designated as "private" and using them in an encryption operation compromises the security of that message. To prove you wrote the ...

2

I think your key doesn't work, because it is only a signature key. That's subpacket 27, for which pgpdump says: Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data The corresponding output of gpg -vv mykey.pub is :signature packet: algo 1, keyid ...

2

As for the first reason: in the future you probably need the decompressed form of the message. There won't be much you can do with the compressed message. But PGP is application level; you may want to verify that message at any time. Now you may want to verify the signature over that decompressed data without compressing it first. E.g. it's a good use case ...

2

No, the master private key cannot decrypt anything encrypted by a subordinate public key. Otherwise, it would mean that the master keypair is the same as the subordinate keypair.

2

Your fingerprint is for OpenPGP V4 compatible as it uses SHA-1. The fingerprint is 20 bytes instead of 16 for MD5 used in the older package format. For V4 it is required to extract the public key packet first. This is likely to be the most tricky part, as PGP uses it's own packet format. You'll have to parse the binary data within your base 64 encoded blob ...

2

You say DER, but you tag PGP which doesn't use DER -- and whose publickey block includes a lot of things beyond the RSA values (n,e). The DER encoding of a PKCS#1 RSA publickey of 4096 bits with a conventional e of 65537 (default at least for openssl and Java) is 30 82 02 0a 02 82 02 01 (n with leading 00) 02 03 01 00 01 with a total length of 526 ...

1

Hi, welcome to Crypto.SE. I would not consider your case to be a cascading encryption. The reason why is the fact you need multiple interventions before getting access to your file. Here is what I would consider a cascading encryption (let's go crazy) : $$E(k_1,k_2,k_3,m) = \text{KEYAK}(k_1,\text{NORX}(k_2,\text{AES}(k_3,m)))$$ which you would decipher ...

1

The inventors of the Supersingular Isogeny Key Exchange, Defeo, Jao and Plut have posted some code on GITHUB at: https://github.com/defeo/ss-isogeny-software/ There is also a paper on implementation of this key exchange by some people from the University of Waterloo. Their paper is "Efficient Implementations of A Quantum-Resistant Key-Exchange Protocol on ...

1

Keeping a complete history of messages/keys Perfect forward secrecy is great to protect "stream kind" of messages, but that does not really fit what OpenPGP is (mostly) used for. Often, OpenPGP messages are sent and read from different machines, at different times, in different order. While OTR (offering perfect forward secrecy) does not rely on external ...

1

I'm going to describe two options that you have. There may be more that I don't know about. The first is to use long-term signing keys to sign public diffie-hellman keys. Upload a bunch of those to the cloud. Then when someone wants to share a file with you, they: download your "next" signed public diffie-hellman key verify the signature using OpenPGP, ...

1

Yes, this could be done. It would be easy to implement and use this in a way that would be horribly insecure (e.g. with too short a passphrase, and not enough key stretching), but if used carefully, it could even be secure. Basically, what you'd do would be: Generate a secure passphrase, e.g. a sequence of randomly chosen words. This can be done ...

1

PGP [1024-bit] digital signature vs SHA256 HMAC Comparison... First, you can compare asymmetric and symmetric algorithms. A 1024-bit asymmetric key provides about 80-bits of security. A SHA256 HMAC provides about 128-bits of security. With all other things being equal, the HMAC is stronger. Second, I believe PGP (or is it GnuPG) uses Lim-Lee primes and ...

1

Questions like these are hard to answer because who can predict what the future holds, right? That said, there are some things I wanted to share. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. From NSA ...

Only top voted, non community-wiki answers of a minimum length are eligible