What is Reddit's opinion of
GnuPG?
From 3.5 billion Reddit comments
➔ GnuPG website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
GnuPG is working for the safety and security of emails and software packages (crypto tools) that are used by virtually every single non-Windows server on the planet.
They have a fundraising campaign going on where you can give BTC: https://www.gnupg.org/cgi-bin/procdonate.cgi?mode=preset .
> Their code was able to lift a secret 256-bit key, used to cryptographically sign data, from another program while it performed a signing operation with libgcrypt’s Curve 25519 EdDSA implementation
So... were they able to reproduce the issue using *any* encryption method, or just that one... If it's just the one I can see exactly why intel would say 'just write better TLB resistant code' since other encryption schemes weren't broken with this... Like I don't know a whole lot about crypto, but the test seems severely lacking/narrow at this point.
I agree! You can donate here: https://www.gnupg.org/donate/
Edit: Just donated myself. If you placed an order on the original Silk Road and used PGP, this man's code probably saved your ass from LE.
I was about to buy Alice on steam for $5.
Found a better home for that $5.
EDIT: it took forever for the site to update after i donated, but here is the list of donors. Just wanted to prove I really did donate :3
Not really. It's also his lingo, his vernacular, his words that are just way out of touch from a 'techie'. This guy is purported as a security(technology?) analyst: the kind of person that's supposed to know shit. He's an idiot.
- "How to hack things"
- "Password app"
- "Change the 's' to a dollar sign"
- "Consider using encryption"
I'm not a psychologist, nor do I analyze speech or word choice/body language professionally, but "Consider using encryption" sounds like the kind of thing someone that doesn't know what encryption is or how it works would say to sound more educated. This is CNN, the vast majority of their audience are tech illiterate. Saying "Consider using encryption", to me, sounds like the kind of thing you would say to ignorant people to make them think you're valid or qualified to be talking about this issue. He doesn't explain how to use encryption or what encryption is. It's one of those buzz words to make you think: "Wow this guy is really smart".
That's my take-away at least.
(Or CNN pays him to talk to the LCD of the CNN audience.)
To be clear, you absolutely should be using encryption if you're backing things up with a third party. GPG, learn it, use it, love it.
GPG Reaper
TL;DR: Obtain/Steal/Restore GPG Private Keys from gpg-agent cache/memory
This POC demonstrates method for obtaining GPG private keys from gpg-agent memory under Windows.
Normally this should be possible only within 10 minutes time frame (--default-cache-ttl value).
Unfortunately housekeeping() function (which is responsible for cache cleanup) is executed only if you are using GPG (there is no timer there).
This means that in normal GPG usecase like: you sign some file then close GUI and do other task you password is still in gpg-agent memory (even if ttl expired).
Attacker, who has access to your current session, can use this for stealing private key without knowing your passphrase.
Introduction
GPG-Agent is a daemon to manage private keys independently from any protocol.
GUI interface communicates with agent using Assuan Protocol.
By default agent caches your credentials.
--default-cache-ttl n option set the time a cache entry is valid to n seconds.
The default is 600 seconds. Each time a cache entry is accessed, its timer is reseted.
Under Windows sign process looks like this:
Crucial part here is housekeeping() function which is responsible for removing expired credentials from the memory.
But there is one problem here: this function is executed only in two places (inside agent_put_cache and agent_get_cache).
This means that cached credentials are NOT removed from the memory until some gpg-agent commands which uses agent_put_cache or agent_get_cache or agent_flush_cache are executed.
https://www.gnupg.org/gph/en/manual/x135.html
http://www.pgpi.org/doc/pgpintro/#p10
I will leave these links here explaining pgp and signing, because I believe there are people trying to disinform by interchanging the words private key, public key, pgp, and hash very often to muddle the issue. From the 2nd link:
"The basic manner in which digital signatures are created is illustrated in Figure 1-6. Instead of encrypting information using someone else's public key, you encrypt it with your private key. If the information can be decrypted with your public key, then it must have originated with you."
This should help clear up the issue, and this is what I think people are complaining about. I think it's important to think about the issue from two perspectives
If he is compromised:
If assange had taken precautions and encrypted his entire hard drive (which he probably would have), then any laptops seized during the alleged raid containing his private key would be inaccessible. Thus, alphabets roleplaying as assange would be unable to make a message, encrypt it using the private key, and allow people to use his public key to verify it.
If Assange is not compromised:
Assange may be frustrated and not want to play into the hands of disinfo agents pushing the 'assange is dead' meme to distract from digging through leaks or to call into doubt his authenticity or the authenticity of any files released by wikileaks. He may think that if the raid did happen, his private key would fall into their hands anyways, so it won't satisfy people who have doubts if he is alive. Further, he doesn't want to make an appearance on the balcony because of real threats to his life.
Stay skeptical, my friends
I get that this is legally the case, but it makes no sense.
email, an electronic method that can require a secure, encrypted connection and username/password combo to access, and can additionally be encrypted or signed to verify authenticity relatively easily is not secure enough for legal or private documents.
A fax, that goes unencrypted over standard telephone lines, that could be tapped or severed or spoofed, and then after printing sits in a fax machine's tray, probably in a central area where anyone in the office could see it, steal it, or replace it is just perfect for legal or private documents.
>You cannot change the data in a fax as it is transmitted.
You could change the data in a fax, the same way you could change the data in an email or physical mail, with a man-in-the-middle attack. And I bet that with current VOIP technology splicing the phone cord in the sending office, then at the same time spoofing the sending number and sending an altered fax to the intended recipient is much easier than breaking the SSL encryption for a MITM on a secured POP3/IMAP connection, or hacking into the mail server.
Email is at worst just as insecure as a fax, and at best much much more secure.
You can use GPG (open source version of PGP) for the purpose: https://www.gnupg.org/. I cannot remember if it's installed by default though.
To encrypt a file you simply do (after generating your key): gpg --encrypt --recipient foo.tgz
To decrypt it afterwards you do: gpg --output foo.tgz --decrypt foo.tgz.gpg
I do believe that several file managers has built-in support for GPG in case you don't want to use the command line.
>Miten esimerkiksi valvot toisen sähköpostiliikennettä jos hän ei edes käytä sähköpostia?
Voi käyttää sähköpostia kun opettele käyttämään gnupg:tä ja opettaa kaverit kanssa käyttämään sitä
>Miten profiloit ihmisen jos hän ei jaa tietojaan internetissä?
> Voi käyttää sähköpostia kun opettele käyttämään gnupg:tä ja opettaa kaverit kanssa käyttämään sitä
Inb4. kryptografia kielletään kansalaiskäytöstä, ja Tor'n, VPN:n tahi PGP:n käytöstä sakkoja tai vankeutta.
Your browser communication is actually an example of something that is encrypted with state of the art ciphers. When sites are deemed "secure" by the browser (green lock icon in Chrome or Firefox), it's using something called TLS behind the scenes to encrypt all of your data between the browser window and the server.
TLS uses algorithms like AES and RSA. Those are examples of top notch encryption schemes. Both of them are simple enough that you could run them with pencil-and-paper, but modern implementations of those algorithms involve many iterations of repeated steps that might be boring and lengthy for you to perform by hand :P
For practical application: GnuPG is a piece of free standalone software that can encrypt single files for you if you want to keep things secret. It uses modern, unbroken (that we know of) ciphers.
Finding the Bitcoin donation address is a bit convoluted, so here is the address: 12LKeo24XCzgz6ASSxcUa8BvUfzkEyCpGq and the QR code (via WolframAlpha)
(You can verify that by clicking the "Wau Holland Stiftung" link in the wall of text here, and selecting Bitcoin in step 2.)
This is how politicians work... To quote some Australian idiot (that was the prime minister):
> "The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia."
So, don't expect politicians to use things like logic or even common sense to try and navigate through this quagmire. In the mean time, download GnuPG.
Trial division to start with: https://primes.utm.edu/prove/prove2_1.html
After that it does a Fermat test and more rigorous tests.
It is actually documented :-) https://www.gnupg.org/documentation/manuals/gcrypt/Prime_002dNumber_002dGenerator-Subsystem-Architecture.html
DO NOT use this to send passwords or credit card numbers!!!
This is in NO WAY secure enough to transmit sensitive information. If the server or communication channels are compromised, your 'secret' will be free for the taking. This is no more secure than using basically any other website to send your secrets, save the purported 'one-time-use' URLs. You may as well use SnapChat to communicate credit card info at that point.
If you must transmit sensitive information, use PGP encryption. GnuPG is a great add on for email, read more here: GnuPG.org
Otherwise, this is a neat website with a clean UI. I'm not sure of a good case for use, but it certainly isn't sharing credit card details.
Exactly, a deterministic machine such as a CPU can't create randomness out of nothing.
That said, if you're working on an application that requires true randomness, such as cryptography, there are other sources out there which you can use to seed your generators. random.org uses atmospheric noise to generate randomness, for example. Programs such as TrueCrypt collect mouse movements from users, and gpg collects usage data from your system since these processes are human-generated and thus generally random as well.
No wrapper? Make one!
Get GPGME, invoke rust-bindgen on gpgme.h and copy the outputted module file into your project. You can use the generated bindings in unsafe code or you can wrap them in safe types. The former is faster for quick one-off apps but the latter produces more reusable code that can be moved into its own library.
I definitely recommend wrapping any pointers the library expects you to manage yourself in a struct that implements RAII via the Drop trait. It makes things so much easier.
Actually I've just realised that Reddit lets you create profile posts (it's a beta feature, you have to opt in here: https://np.reddit.com/profile-beta-confirmation). This means you can publish your public key in your profile, and then other redditors can then send you encrypted private messages. Here's mine: https://np.reddit.com/user/petermkelly/comments/6nt3wb/brandis_public_key/
This turns Reddit into a end-to-end encrypted messaging system, without them even having to do anything to explicitly support it.
The vulnerability here of course is that the government could theoretically compel reddit to modify your profile so that it uses a public key that they themselves have generated rather than your own. However, this would only affect messages sent to you after this happened, and also you'd be alerted to it as soon as you receive a message and find that you cannot decrypt it.
I do however recommend GPG (https://www.gnupg.org) which does the same thing as Brandis but has been battle-tested for many years; I put the latter together in less than a day and it relies on still-evolving browser APIs for cryptography.
Those are stub keys, which contain no secret data. The stubs are only a map to tell gpg where to find the actual keys.
https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html
keytocard
Transfer the selected secret subkey (or the primary key if no subkey has been selected) to a smartcard. The secret key in the keyring will be replaced by a stub if the key could be stored successfully on the card and you use the save command later. Only certain key types may be transferred to the card. A sub menu allows you to select on what card to store the key. Note that it is not possible to get that key back from the card - if the card gets broken your secret key will be lost unless you have a backup somewhere.
If you wish to bake an apple pie from scratch, you must first invent the universe.
Edit: In more seriousness: https://www.gnupg.org/download/integrity_check.html
What I would do is download two versions of GPG from two different (legit) sources and verify them against each other (checksum and signatures). Not perfect, but would probably be "good enough."
What they were using to decrypt the emails is called GPG (Gnu Privacy Guard). They made it look like a linux terminal and I think they did gpg -d and it shows you a key, then it shows the decrypted emails. gpg is the program, and -d stands for decrypt. Here is the man page for GPG
ah I see.
There's a very good chance that this is what you want: https://www.gnupg.org/
On the download page, scroll down to get to the binary releases. Those are the ones you want.
I'd recommend reading through the documentation on that site. You could start there: https://www.gnupg.org/documentation/howtos.html and in particular http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html
This is just a public key, the public half of a keypair used in asymmetric cryptography.
If you'd like to know more, here's the chapter on key exchange in the GNU Privacy Handbook: https://www.gnupg.org/gph/en/manual/x56.html
It means you have imported the public key (from the software you're verifying) but you haven't verified the public key as trusted. For instance, let's say you've downloaded the public key from some software's website, how can you actually trust that key is legitimate? Ideally you'd need proof from the developer that the fingerprint of the key is correct.
If you have verified that the key belongs to the person it is supposed to belong, you can run a command to trust the key:
gpg --edit-key 'KEY_NAME'
and then type trust. After that you will need to answer which degree of trust you have as:
1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu
Some readings on this topic:
GPG Reaper
TL;DR: Obtain/Steal/Restore GPG Private Keys from gpg-agent cache/memory
This POC demonstrates method for obtaining GPG private keys from gpg-agent memory under Windows.
Normally this should be possible only within 10 minutes time frame (--default-cache-ttl value).
Unfortunately housekeeping() function (which is responsible for cache cleanup) is executed only if you are using GPG (there is no timer there).
This means that in normal GPG usecase like: you sign some file then close GUI and do other task you password is still in gpg-agent memory (even if ttl expired).
Attacker, who has access to your current session, can use this for stealing private key without knowing your passphrase.
Introduction
GPG-Agent is a daemon to manage private keys independently from any protocol.
GUI interface communicates with agent using Assuan Protocol.
By default agent caches your credentials.
--default-cache-ttl n option set the time a cache entry is valid to n seconds.
The default is 600 seconds. Each time a cache entry is accessed, its timer is reseted.
Under Windows sign process looks like this:
Crucial part here is housekeeping() function which is responsible for removing expired credentials from the memory.
But there is one problem here: this function is executed only in two places (inside agent_put_cache and agent_get_cache).
This means that cached credentials are NOT removed from the memory until some gpg-agent commands which uses agent_put_cache or agent_get_cache or agent_flush_cache are executed.
I was trying to understand the technical details behind some of the security claims, and came across this: https://wiki.tox.chat/users/faq#encryption
It says: "Thanks to public key cryptography, it is also impossible to pretend to be another Tox user, unless you were to steal that user's private key."
That feels like hand waving to me. In order to communicate with somebody securely, you need to first be sure that the public key belongs to that user. Without solving this, the scheme is likely vulnerable to man-in-the-middle attacks.
See: https://en.wikipedia.org/wiki/Public-key_cryptography#Associating_public_keys_with_identities
Solutions to this include relying on a trusted party (certificate authority), the web of trust, or requiring users to verify keys belonging to identities out of band. For example, see GPG recommendation: https://www.gnupg.org/gph/en/manual/x334.html
How does Tox solve this problem?
Take a look at GPG: https://www.gnupg.org/
It's meant for encrypted messages, but it can easily be used to encrypt files as well. It's more secure than an option such as 7-Zip's AES encryption due to the fact that it uses public key cryptography. That means the key capable of decrypting the file doesn't need to be exchanged or agreed upon before your friend is able to decrypt it. You simply encrypt a message/file to someone's public key, and their private key is then able to decrypt it.
It's more secure than having to agree upon or tell your friend a password, as that communication could be eavesdropped upon.
No, do not use encryption software that is not open source. You never know if it is compromised or backdoored. Also why would you want to pay for something when there are better free alternatives?
You can encrypt your entire hard drive which is something inbuilt into most Linux installers (if you care about security you shouldn't use Windows or Mac).
Mac does however have disk encryption called FileVault, but again you don't know if it's compromised or backdoored. Certainly better than nothing so enable it.
Otherwise to encrypt individual files on any operating system try GNU privacy guard.
Public key is a thing you encrypt stuff with when you want to send something encrypted. Only a person with a private key can decrypt the data. In the meme, u/VanillaWaffle_ refers specifically to the GNU Privacy Guard. More info
You can use it to sign messages so a recipient using GPG can verify that nothing has been tampered with, or you can encrypt messages with a recipient's public key so that only they can decrypt it (or whoever has access to their private key).
That last bit is important and the reason private keys need to be protected. I generate mine offline on a Raspberry Pi and store them on a Yubikey. This is a good guide for doing this.
You don't have to do it offline on a clean system, but its good practice to keep your private key safe. If you're not very familiar with linux or the command line, the learning curve is a bit steep. Try it out with a friend and don't communicate anything sensitive until you're familiar, then wipe those keys and start fresh.
And here we have the prime example of the problem with asking for privacy and security advice on Reddit: any random user can come in and spout privacy-harming nonsense.
> it is perfectly OK to store your private key (as exported from Kleopatra) online
This is categorically poor advice.
Saying that it's no big deal to store your private key publicly because the private key is symmetrically encrypted goes against established key safeguarding best practices (like the GPG Privacy Handbook, or NIST Key Management standards).
By storing your private key publicly, you are voluntarily bypassing one of the crucial primary safeguards: the fact that no one has your private key, and so is not even able to try to decrypt it.
Your post is like saying 'well, it doesn't matter if you store the safe that has the keys to your house in the middle of the street, as long as you have a good pincode for your safe, they won't be able to break into it anyway'.
No way! A man page is a much better alternative.
In practice -h output is mostly useless—it’s neither simple enough for a quick overview nor comprehensive enough to actually know what I can do! Tried “less --help” lately? It spits out ten pages of output!
Plus, every program does --help differently. Does it spit out short output or tons of output so that I need a pager? Does it fork and execute a pager itself, or do I have to run the program again and pipe it to less manually? And then it turns out some programs print --help output to stderr, not stdout, so the pager doesn’t display any output until I do “blahblah --help 2>&1 | less”.
A well‐written manpage is so much nicer. It provides a consistent interface, and has a SYNOPSIS section so I don’t even have to page down to get a brief overview. But if I really need the verbose information, I can just hit space a couple of times.
Really, horrendous and arcane manpages are a trope that mostly exists in the Linux/GNU world. In BSDs, especially OpenBSD and FreeBSD, clear, simple documentation is a priority. No need for --help or “bropages” when the actual manpages are perfectly clear. For example, check out OpenBSD’s signify(1) manual, used for cryptographic signing and verification. Compare that to the monstrosity that is gpg(1)…
Thank you for volunteering to be an example of the wide neglect of not verifying public keys. See also The GNU Privacy Handbook
> Once a key is imported it should be validated. GnuPG uses a powerful and flexible trust model that does not require you to personally validate each key you import. Some keys may need to be personally validated, however. ... A key's fingerprint is verified with the key's owner. This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner.
You don't need to verify a key if you have a path to the end user's public key in your chain of trust (though you better hope that everybody in that chain followed the right process, or else it is not a very trustworthy web of trust). In practice, you often will not have that path.
It sounds like you want to learn gpg. You don't even need two computers. You can email encrypted messages to yourself over the internet.
If you want to learn about the mechanics of encryption, use gpg to encrypt a file to yourself, and then decrypt it again.
Here's the manual: https://www.gnupg.org/gph/en/manual.html
You can donate directly to Werner here: https://www.gnupg.org/donate/index.html
Update: /r/linux /r/bitcoin /r/privacy and /r/rad_decentralization rallied in support and he has now reached his €120000 funding target with some extra within a day. Awesome.
So I came into this article thinking it couldn't possibly be that bad and play devil's advocate.
I didn't get past the second paragraph without changing camp.
> GNS employs the curve parameters of the twisted edwards representation of Curve25519 [RFC7748] (a.k.a. edwards25519) with the E*C*DSA scheme
WHAT THE FUCK
WHAT THE FUCK
WHAT THE FUCK
> The inclusion of a hash function under the hood of the signature algorithm is a moot point, especially since RFC 6979 also uses HMAC-SHA2 to generate deterministic nonces, thereby rendering their choice of RFC 6979.
Did you accidentally the end of that sentence?
> GnuTLS is an SSL/TLS library created by the same people who created (and then abandoned) libmcrypt
I never knew that they shared origins. This explains a lot, actually. Thanks for pointing that out.
> [libgcrypt sucks from a security standpoint]
It does, but have you ever tried to use the asymmetrical primitives? It also sucks from an API standpoint! It's complicated management of S-expressions all the way down. It's horrendous.
I rather like the rest of the libgcrypt API design though (at least as opposed to whatever it is OpenSSL's libcrypto is subjecting us all to), but that's the only part of libgcrypt I can say I genuinely like.
> If you see the letters GNU anywhere in a project that intersects with cryptography–except for its public license–it’s almost certainly an error-prone cryptographic design.
Do not look under the hood of any GNU project. I mean it. You do not want to see it. There are exceptions, but in genreal, you'll sleep much better if you don't know that GNU true(1) has introduced an obscure failure mode that makes it possible for it to return false (true --help>/dev/full; note you may need to use env true to bypass your shell's builtin).
You probably want to use GPG, not OpenSSL.
With GPG, you each generate a public and private key. You share each-others' public keys, and use them to sign and optionally encrypt messages between yourselves. This allows you to know that the message came from your friend, and when encrypted, that only your friend can read it- not even you can decrypt the message.
In this case, not really. This isn't an encrypted message, but rather a signed message. It's almost the same, except the message stays in plaintext and the signature just verifies that OP's friend is the one who actually sent the message.
Guys, is there anywhere i can donate to this guy, directly?
I can't find anything, but i want to donate to him.
EDIT: Found it: https://www.gnupg.org/donate/index.html Let's show them some love.
almost yes, when using public key encryption, gnupg will transparently generate a symmetric session encryption key that is used for actual encryption.
This slide (nr8) from An Advanced Introduction to GnuPG shows quite well how the data and keys are used.
There is also a really interesting 2 hour presentation using those same slides https://www.youtube.com/watch?v=fX0pgV8hPq8 (well it was fun watch for me but i'm a hardcore nerd with lots of free time :D)
Main point is that Yubikey never sees the full file that is decrypted and is always quite fast.
>key compromise
Pregenerate a revocation certificate and store it somewhere safe. If your key is compromised, publish this certificate which invalidates your key. There is no way to rescind a key revocation.
>paper backup
http://www.jabberwocky.com/software/paperkey/ can help with this.
You will need to import the public key that signed the software into your GPG keyring, then you can check that key (verify it comes from who you think it does), then verify it (bottom of the page, under 'Detached Signatures')
This looks to be a good guide from Tor: https://www.torproject.org/docs/verifying-signatures.html.en
Edit: .gpg versus .asc really don't mean anything to this. One could output a ASCII Armored signature to a .gpg file, though convention does seem to be armored output goes to .asc. The two file types are effectively interchangeable.
> If you are checking integrity from a remote source md5 is not good enough anymore, as a collision can be trivially created.
In simpler terms, an MD5 hash is sufficient to rule out data loss or corruption, but it can not be relied upon to prove that a file has not been tampered with maliciously. Generally speaking, if the file size and the MD5 hash match, then you may feel assured that the file downloaded completely and no part of it was corrupted in transmission. You may not feel assured that the file is authentic, and has not been tampered with since the original MD5 hash was generated.
If you want to verify the authenticity of a file, to prove that it is the same file which originated from a trusted source and has not been tampered with, then the best bet is to obtain a cryptographic signature directly from the trusted source, and verify the downloaded file against it. It would be exceedingly difficult for an attacker to alter the file in such a way that it would still verify against the original signature.
The problem here is the use of v3 keys, right? Such keys are no longer supported by GnuPG as of version 2.1, which was released in November 2014. (The originally-linked message is from October 2014.)
If one is using GPG 2.1.x, is there any reason to worry about the issue presented here?
A direct link if anyone would like to donate.
Another project which had run into similar problems is OpenSSH, one of the most unsexy yet crucial applications I use on a daily basis.
Ultimately you will want to understand the straightforward underlaying OpenPGP message format which can be found in RFC-4880[1]. When using GnuPG from another program you would want to use GPGME[2]
The thing you will have to learn is practical cryptograpy as applied to public key cryptography and cryptographic signatures. There are many books devoted to that/those subject(s).
You need to provide more requirements.
- Use a zip/7z file with password.
- Use vim encryption (https://www.geeksforgeeks.org/encrypting-files-using-vim-editor-in-linux/)
- Use GPG (https://www.gnupg.org/gph/en/manual/x110.html)
- Encrypt the whole block device (LUKS isn't tied to the physical computer).
- Encrypt the filesystem (encfs)
- Many other solutions.
You are wanting to use gpg to encrypt a file with a public key whose corresponding private key you control exclusively.
can you expand a little on what you did prior to attempting to verify? also, may want to re-download the installer and the signature and try again.
$ gpg --verify npp.7.7.1.Installer.x64.exe.sig npp.7.7.1.Installer.x64.exe gpg: Signature made Wed 19 Jun 2019 05:47:38 PM MDT gpg: using RSA key 14BCE4362749B2B51F8C71226C429F1D8D84F46E gpg: Good signature from "Notepad++ <>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 14BC E436 2749 B2B5 1F8C 7122 6C42 9F1D 8D84 F46E
As for the Marginals, that is a level of trust that you would assign to the key "Notepad++ <[email protected]>". Levels of trust are Unknown (-), ? (q), None (n), Marginal (m), Full (f), Ultimate (u). ^I ^can't ^find ^a ^source ^for ^the ^q ^level ^of ^trust. Ultimate is reserved for keys you personally control.
In your case, since you have not signed or assigned trust to the NP++ key, it has a [unknown] trust level. That will have no effect on actually verifying the .sig on the .exe, and GPG is just letting you know that you have not yet verified and signed the NP++ key.
jbuilder is used for json generation, so I assume you mean builder. Message encryptor on a flat file would be the equivalent of using gpg. I would prefer gpg. https://www.gnupg.org/gph/en/manual/x110.html
In the post, I shared a way of using two open xml based standards (xmldsig and xmlenc) for signing and encryption. In what I am aiming to be a ruby friendly way.
The example is contrived but a real world example is using xml-kit for generating SAML messages.
You need to build a web of trust by getting other people you know to sign your key.
However, most people tend to not check pgp signatures at all so most likely forgers won't even bother signing things in the first place. Not a huge amount you can do about this and is one of the big flaws with email in general.
If you communicate with someone you know regularly and both use pgp to sign your messages then you will have a copy of each other public key that you trust and you can verify the messages against that - not just that the name in the key is yours, but the actual public key. If anything the name is just a convenience not actual security so you should never rely on it.
If someone else then tries to create a new key, the public key won't match your copy and you will know it is not legit. The web of trust gives you confidence that lots of people have validated your public key so it is more trust worthy than other potential keys out there with your name on them which is useful when you first obtain a public key for someone. After that however it is the public/private key that protects you.
Sooo, basically a signature?
There's a diminishing return of rsa keys. We are costing more while getting less security benefit when using 4096 rather than 2048.
Tough I use 4096 for my pgp key. I did not read that when I was generating my key ._.
Yes. This was never really about weaknesses in GPG, just buggy integration to GPG by mail clients, as the GPG developers nicely explained. Your GPG encrypted local files are as safe as ever. The CFB attack might allow an attacker to insert a chosen plaintext to the beginning of your encrypted file, but he would need to have write access to the file to begin with - at which point messing with your encrypted file is probably your least concern.
If you really need guarantees that the integrity of your encrypted files has not been compromised, you can sign them with your private key (that needs to be protected by a strong passphrase, and preferably, stored on a separate device from the encrypted files.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I don't see what is so hard about setting up a key, personally.
Install GnuPG (https://www.gnupg.org/) (even easier on Linux), run
gpg2 --full-gen-key
in a cmd window, follow the ~5 simple prompts, wait a few minutes, BAM! Key!
Exporting is as easy as
gpg --armor --output mypublickey.gpg --export [any key identifier]
then just copy the contents of mypublickey.gpg and you can post them anywhere and everywhere to make sure that everyone has them.
Just for the sake of example, I created a key for reddit following these steps. Here
Also, signed this post. -----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEDyeWvm+tdZIbr3Bx8RBV/5Mi3IIFAlg2ZxYACgkQ8RBV/5Mi 3IICHQ/+JlIEvGu0UCLUkYV+vK+9ImmC1Rb9SbEIv+ttLCWumpRFuCIjrkjd4vwF csxJ3eUM0yRHx2OXIFImbwTxgdhcjW2eZnrtNwO3A+eFJNb+FEgsFgSt1dddA4lB GnjMF0cCKhN6BBUuWLp3p9zPrlzEH9aWE0tg3xei4DZohVIRtYeqtLv0uniTajeg 8pDG6ULca8Ntgd7HWVV9gCqtpA35zejiCGK4iOByB9mV94e19BCOe6FygT8NHr+j MNi4nkvA5fZboj2zhwvc6yfGLRO8b0AFgTuleAK6diMxJIWwXILmEnfN5QXX6P5K P+/dWYMk+XMj0LbdUwwtCCIhgTupPGwWpOFBQAqtscZbXtIoLLG6w7lqH3kSeGML Xqo2FuY5ib811ji2ADK7aqK1a8UPmqOBxlW1p1Uh5lQEsWXMQ5QNKxVISH/mgje1 APGhArsQPtxuGnaxOSkCggZJTJZp7EyL7AGEjn7Ht8vXt7cO+Zkqa+zTvfqaYMYa lSX2tHzkN5tGflHYtsFetNRsDfRLDENMecaAxQeTKMqQd0GrUGGNfr4QRBFm7WH4 j5j2S+VDsCGe2tIMcpGtrLslGfasZSeIwJ77jnKRpfzZIbn/yZw5ngL7oM8txUf2 hIKu2CfFJ52kx2MuLIBkHsMm4aZeKsYmgh5fwPpQv80TucsVEno= =VYPo
-----END PGP SIGNATURE-----
Straight from the Wikipedia on PGP:
> Digital signatures[edit] PGP supports message authentication and integrity checking. The latter is used to detect whether a message has been altered since it was completed (the message integrity property) and the former to determine whether it was actually sent by the person or entity claimed to be the sender (a digital signature). Because the content is encrypted, any changes in the message will result in failure of the decryption with the appropriate key. The sender uses PGP to create a digital signature for the message with either the RSA or DSA algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext and then creates the digital signature from that hash using the sender's private key.
If you've noticed Wikileaks predominantly displays their public key on both their web site, and their twitter. This was setup in case anyone ever questioned the authenticity of wikileaks' messages.
This site: https://www.gnupg.org/gph/en/manual/x135.html explains how to create and validate PGP signatures.
The Eli5 version: PGP Signatures take your message and apply mathematical operations to the message with your secret password. If someone has the "decoder" side of the password they are able to validate with reverse operations of math, the authenticity of the message.
Think of it like pig latin; you and I share with eachother that we are going to move the first letter to the back, and add "ay" as a trailer.
When I say "ipay atinlay" you know that I am saying "pig latin" by subtracting "ay" and moving the last letter to the front.
This is not exactly how it works, but it is as close to an ELI5 as I can get :)
Digital signatures involve asymmetric cryptography, which relies on the person digitally "signing" something to share something (actually just a big long number) that, when applied in a mathematical formula to the thing being signed, will end up with an answer that means "Yes, this signature is valid for this text." If the signature isn't valid, or the number that the signing person shared is the wrong number, then the computer will interpret the answer as meaning "no, this isn't a valid signature."
The tricky bit about "proof" that the message comes from you is that people have to trust that the number you share -- called the "public key" -- actually came from you and not someone impersonating you. It's pretty difficult to do that generally with people you haven't met. Some people using public key encryption have "key signing parties" to crowd-source this, or companies like Verisign will charge you for different levels of identification verification.
The other tricky bit is to keep another number -- the one used to "sign" the text, called a "private key" -- completely secure, because if someone gets it they can forge your signature.
One common set of free software used to do public key encryption and digital signature is called GNU Privacy Guard but it can be a bit of a chore to use.
So... What about these:
https://www.gnupg.org/related_software/frontends.html
I see in another comment you responded that seahorse, one of the front ends listed on gnupg.org, 'only does key management'. What else do you want to do with gpg from your tool?
For encrypting / decrypting / signing / verifying files, the CLI tools make that pretty simple; the only 'complex' thing about gpg is key management, and there already appear to be numerous, stable and well developed, tools available for that.
Yeah, that's because you can have mu4e fetch your mail and update the database periodically (see mu4e-get-mail-command and mu4e-update-interval) and to do that, your program of choice (OfflineIMAP, isync, etc) would have to use your key for decryption.
When you unlock a key, the GPG agent caches it for a specific amount of time, before asking for password again. This interval is somewhat short by default (10 minutes). So if your mu4e update interval is larger than the cache time of GPG, you'd have to enter the password on each update.
To work around this, you can create ~/.gnupg/gpg-agent.conf and set default-cache-ttl to increase the cache time of your keys. Note that there's a maximum of 2 hours, so if you want to cache your keys for longer than 2hrs, you'd have to set max-cache-ttl as well. See the GPG Agent Options.
Yes, you should always generate revocation certificates when you generate a new key. Print them out and keep them somewhere safe. You'll need it if you ever lose your private keys. The public keyservers are full of abandoned keys that can never be revoked because the owner has lost their private key.
If you individually import, and mark trusted each others' keys, there's little benefit to signing each other. But that requires manually maintaining your local trust store. By signing each others' keys, you're telling gpg to trust what you've signed, and what keys those keys have signed. That's the way gpg was mean to work, so you'll have the best experience if you stick with it. After verifying the key you have in front of you belongs to who you think it does, you sign their key and give them your signature of it. The easiest way to do that is to push it to a keyserver where everyone can retrieve it. Distributing keys on flash drives can work, but again, it's not the way gpg was meant to be used and has some downsides. It'll either take longer (if you only use one) or it'll be hard to get everyone to the same view of the keys (if you use multiple drives). It's easy for someone to tamper with the keys (replace them) and if you aren't carefully checking fingerprints, it might go unnoticed. There's little reason to do your signing offline if the computers housing your private keys are going to be online later.
Don't do that. it's missing the entire point of gpg. Signatures no longer mean anything. You can no longer restrict who among your group can decrypt messages. You lose key control (any of the group can share it, intentionally or not, with anyone else.) The "simplicity" argument doesn't stand either. You still have to transfer keys, except now you're transferring private keys instead of just public.
PGP stands for Pretty Good Privacy.
It's a public key encryption system, see https://en.wikipedia.org/wiki/Public-key_cryptography
It does not make you anonymous. It secures your communications and allows you to sign/crypt/decrypt/verify files.
How to get started: https://www.gnupg.org/download/index.html
Since all you're encrypting is a file for protection of data at rest, there may not be a need to either containerize or provide on-the-fly decryption.
<code>openssl enc</code> or <code>gpg -e</code> on the file would work...
Work on local copy, encrypt into location used by cloud storage.
Synchronize.
Decrypt stored file into local copy elsewhere.
Even 2048 bit keys wont become easily crackable until ~2030, and we do have 4096 bit keypairs to generate at the moment. As you increase the key size, security doesn't increase exponentially, you get diminishing returns.
RSA-2048 gives ~112 bits of security, and RSA-4096 ~128. So while 4096 bit keys are stronger, they're not much stronger.
http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-size
https://www.gnupg.org/faq/gnupg-faq.html#advanced_topics
You would have to download gpg, since you're on windows, and learn how to use that to verify the signature.
Animazing's an Electrum Dev, but to trust the key fingerprint given there, you would have to have a trusted source who will attest to the correctness of the key.
Apart from electrum.org, you can refer to this reddit thread in which animazing declares his public key and it's vetted by others, I also can attest to it, his fingerprint is
9914 864D FC33 499C 6CA2 BEEA 2245 3004 6955 06FD
DES was released in 1977 and it still hasn't been broken, though the original key size was too small.
It is only asymmetric encryption algorithms (RSA, ECC) that are fragile and need to be re-keyed every 10 years or so. If you use GPG in symmetric mode nobody is getting at that data for a very long time.
The 12 word seed isn't a private key in the usual sense. It is the random number from which all future private keys for that wallet are generated. It needs to be well protected, as an attacker can use it to steal any and all coins placed in any address in the wallet, regardless of any password placed subsequently on it.
Just use any solid encryption utility, such as GPG (Gnu Privacy Guard) to protect it.
Thank you all for your replies.
Taking your feedback, I've decided I want to start double encrypting my files like so:
File -> GPG (Serpent256 + SHA512 + Symmetric) -> GPGFile1 | GPGFile1 -> GPG (AES256 + SHA512 + Symmetric) -> GPGFile2
My only question is, how do I start using Serpent. On the page of Available Ciphers it says that Serpent256 is an option, but when I go and try to use: gpg -c --cipher-algo SERPENT256 it returns that that isn't a option.
Thank you all again for your feedback.
Yup, GNU pass should be a lot better than this, and by building on GnuPG it unavoidably inherits the problems of both GnuPG and OpenPGP.
> Let's to the command to export our GnuPG keyring to a file
The exported S2K protection is different than than the protection used on the keyring, so you can't infer anything about GnuPG keys at rest unless you're storing them in exported format rather than on your keyring. This changed in GnuPG 2.1, and that's why the S2K options are silently ignored as of GnuPG 2.1. I'm the person who filed the bug report discussed in the video, and the responses to that report are how I learned what's going on. These S2K issues are what originally stopped my use of GnuPG, except for gpgv (the only component with a sensible architecture) to verify signatures.
That being said, SHA-1 and AES-128 being fast doesn't matter since they're just primitives in the overall S2K scheme designed to be slow (i.e. the S2K iteration count). All the major password-hashing algorithms are built on fast primitives like this, including PBKDF2, scrypt, and Argon2. Also, SHA-1 is still safe as a primitive for password hashing since none of its weaknesses apply. A new application shouldn't choose it, but existing applications aren't broken or at risk for continuing to use it.
Yes, it should be possible.
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html
If it were me, I'd copy the contents from persistence (the GPG data) onto a trusted system. If it were me I would backup the current disk incase of hardware failure.
I'd copy the GPG data onto a new, trusted disk (encrypted or one you are going to physically pulverize/destroy). Create a separate Tails disk.
Boot into the new Tails disk, create persistence, enable GPG persistence. Reboot.
Boot into new Tails, do not enter persistence, just a normal session.
In Tails Gnome Disk Utility, mount the TailsData partition. Insert your backup of your old GPG data. Copy the data from the old GPG disk to your Tails persistence drive over what is there.
Remove the old GPG disk.
Reboot.
Boot into Tails, enable persistence. Attempt to access the keyring using your passphrase. It should work if you know the passphrase.
Once it works, either securely store the GPG backup disk or destroy it (especially if not encrypted, as it may be possible to forensically recover it even if you reformat the disk.)
Did you follow the instructions in the Hint: If you are using Windows follow the tutorial How to verify the ISO image on Windows.? Here is the link....
https://forums.linuxmint.com/viewtopic.php?f=42&t=291093
The tutorial will point you to https://www.gnupg.org/download/index.html - you need to download the "Simple installer for the current GnuPG". You will use this to verify the ISO.
Verifying the content is what signing the message with a key means. You can use GPG to digitally sign a file to ensure that the file came from the sender and was not tampered with since the sender made it.
So I'm not sure what to make of RSA 2048. GnuPG recommends and defaults to 2048 and their reasoning: https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048
​
>Largely, yes. According to NIST Special Publication 800-57, published in July 2012, 2048-bit RSA is believed safe until 2030. At present, no reputable cryptographer or research group has cast doubt on the safety of RSA-2048. That said, many are suggesting shifting to larger keys, and GnuPG will be making such a shift in the near future.
Why in 2019 are people still outraged that when you hand over unencrypted data voluntarily to a third party that they screen and process it.
Easy way to stop Facebook reading your private information; stop volunteering your private information to them.
No worry about asking for more details, I am here to learn too.
You are in the right direction with that latest copy of the NIST Guide which shows, beside 256-bit ECC, that a 512 bit ECC is indeed comparable to RSA-15360. ECC have different curves which you can choose from, e.g. in GnuPG, you can choose NIST P-521 which will be even stronger than RSA-16384.
You can also refer to GnuPG's site that "elliptical-curve cryptography.. bring a level of safety comparable to RSA-16384."
IMO, everybody has something to hide, even those who might boast they have nothing to hide. Your thoughtful comment touches on very important topics, including PGP/GnuPG encryption. Like Tor, PGP/GnuPG preserves my anonymity and protects my privacy whenever I choose to exercise my human right to anonymity and privacy, including the use of free OpenPGP software to encrypt emails, files, folders, thumb drives, hard drives, and more.
GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as PGP). GnuPG allows you to encrypt and sign your data and communications; it features a versatile key management system, along with access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. GnuPG also provides support for S/MIME and Secure Shell (ssh).
> GPG doesn't have a library like most systems of it's stature. Instead it just has a command line app. Other programs just parse the output that GPG produces.
Hi JelkyBelly.
If I understand correctly, you're asking whether the PGP servers perform any kind of identity verification?
The perform NO identity verification. I could generate a PGP key, label it JelkyBelly, and upload it to pgp.mit.edu
The cool news is that there is a "web of trust" built from people signing each other's keys. You can learn more about it here: https://www.gnupg.org/gph/en/manual/x334.html
> The key has been used to verify several uids and I'm not sure how this will influence the web of trust
Just a guess, but I doubt these keys are still taken into account in the WoT. According to GPG 2.1 release notes, they require the use of md5, which is totally insecure, which makes me think no client (should) trust these signatures anyway. But that's just a guess.
Yeah. Pretty much.
Whatever solution they might decide on, it would be impossible to implement it discretely and even if it was a technically viable solution (as in it didn't compromise the actual security of the algorithm itself) there's no way we'd get other countries and companies outside our jurisdiction to sign up to it. We're not so important that we can just create our own bespoke new standards that allows our intelligence services to listen in and have them be adopted by everyone else.
From a theoretical point of view it's doable. It's just not practical and will in no way solve the problems they're trying to address. It'd be hugely expensive (both in the sense of adopting a new way of doing things and in that nobody else would want to be compatible with it) and be useful for nothing more than snooping on petty criminals and society at large. Anyone with even a little bit of technical knowledge can download gnuPG and encrypt messages to their hearts content that'll be unreadable to GCHQ. It's a pointless idea all round.
https://www.gnupg.org/download/index.en.html
Download at this link. Create new key. Right click on key and select copy. This will copy public key. Paste this to profile. Next, right click and select export keys. This will export both public and priviate. Save this file to USB. You need your key saved (program should know pk, just needs password) on HD to decrypt messages encrypted with YOUR public key. Any questions pm me.
I think you're better off encrypting the directory.
GnuPG can do it. Archive the directory (tar) then use GPG on it. Various front-ends exist so you don't have to do it by CLI, and it can even integrate in some file managers.
For on-the fly encryption/decryption, there's eCryptfs: https://wiki.archlinux.org/index.php/ECryptfs#Encrypting_a_data_directory
Re GnuPG v2, you can add no-emit-version to ~/.gnupg/config and it will be removed automatically. (See GnuPG Docs )
Putting yourself as a recipient means you could be compelled at some point to decrypt them, since it is possible. Otherwise you can legitimately say you are incapable of doing so.
ExFAT and FAT32 are not supported disk formats for MacOS' native encryption, and an encrypted DMG will not be able to be mounted/unpacked on a Windows computer, so if you need cross platform encryption you'll need to look to open source tools like GPG which are significantly more complicated.
GPG private and public keys. The user generates a public and private key pair. The user sends you the public key that you would use to encrypt the password from a plain text to GPG format, which you can now email. The receipt will need the private key, which is protected by a password set by the user, to decrypt, so someone else having the GPG file itself does you them no good.
Looks like an interesting tool. At first I thought its like an EtherPad, but with e2e encryption. Would make a good project, too :D
I saw, that you directly call gpg2 from console, you should consider using the official gpg api GpgMe https://www.gnupg.org/%28es%29/related_software/gpgme/index.html - Using the API ensures that the program is working with every version of gpg available.
Sure, anonymity and reputation are an hard trade-off, but maybe it's possible a trusted system like GPG/PGP https://www.gnupg.org/gph/en/manual/x334.html and per transitivity build a trusted anonymous network
I believe it's a unique fingerprint based on the message, timestamp and the private key.
From https://www.gnupg.org/gph/en/manual/x135.html:
> A digital signature certifies and timestamps a document. If the document is subsequently modified in any way, a verification of the signature will fail. A digital signature can serve the same purpose as a hand-written signature with the additional benefit of being tamper-resistant. The GnuPG source distribution, for example, is signed so that users can verify that the source code has not been modified since it was packaged. > > Creating and verifying signatures uses the public/private keypair in an operation different from encryption and decryption. A signature is created using the private key of the signer. The signature is verified using the corresponding public key. For example, Alice would use her own private key to digitally sign her latest submission to the Journal of Inorganic Chemistry. The associate editor handling her submission would use Alice's public key to check the signature to verify that the submission indeed came from Alice and that it had not been modified since Alice sent it. A consequence of using digital signatures is that it is difficult to deny that you made a digital signature since that would imply your private key had been compromised.
The signing of public keys allows one to build up a web of trust - https://www.gnupg.org/gph/en/manual/x547.html
It's the processes of others certifying your PUBLIC key to your identity. People can meet up with a few forms of valid identification to prove who they are and that it matched the identity for the key, and that your fingerprint of their public key also matches their key.
When it's done, a person sending you a message encrypted can trust that your public key is really for you, and when you decrypt the message that it's truly your eyes that is reading it.
NEVER put a private key online - and if you want to be extra careful, keep your master key on an airgap system.
> - Full disc encryption with self destruct on k wrong entries or if typed one self-destruct password like Kali did for LUKS
It's useless against people that really want your data because 1) they will undoubtedly make an image of the data your storage device contains and reflash it if anything happens to the data; 2) if they know the algorithm used, they can just remove this functionality and make it type "Time for advanced interrogation techniques!" instead of destructing the data if a "self-destruct password" is given.
> Metadata free GPG.
What metadata is there that GPG needs to get rid of? There's even <code>--hidden-recipient</code> if you wish to encrypt some data for someone without including their key ID (in which case gpg --decrypt will try to bruteforce with your private keys, you can see that if you also include --verbose).
It's just the fact that it's being used with emails, while still leaving the "subject" field in cleartext, where you trust your email-server to know who you're sending your message to, where some email-servers may even include your IP address into the header of your message.
Maybe KGpg or Seahorse when considering GPG. (via apt and [1])
I am not sure about your 7z reference but file-roller does a good job as a graphical archive manager combined with p7zip.
I've only done proof of concept so far. (Uploaded a few videos). I need to get it scripted so that the whole thing is automatic.
Basically use aescrypt to encrypt your files with a known key. You can also use gpg to encrypt the files. (I didn't want to worry about losing my key).
Then just par/rar up the files like you would any other upload.
Then upload them.
newspost -i news.newsgroupdirect.com -u ***** -p **** -f -n alt.binaries.boneless -y -s "Backup" *.rar *.par2
I use alt.binary.boneless. It just shows up as noise. Given how much I'm backing up it's not much more than a few 1080p blueray movies. If anyone does download it for curiosity it's encrypted. And if they somehow crack AES (we're all screwed) it's just pictures and other stuff I can't lose. I guess if I was really paranoid I could scrub the EXIF data before I uploaded it.
The idea is that every year I'll re-do a 'full' upload so should something happen I'll have 3 years (or what ever retention is up to these days) to redownload my files. I haven't verified but I don't think that uploads count against my quota. Even if it did I could backup 1TB for 3 years for $40.
And if you have technically literate family members you can share photos with a .nzb file.
not to mention that the way encrypted email transfer is established(STARTTLS) is easier to MITM than say, pure TLS web uses. answer to email's flawed to the core security is GPG and even that doesn't solve it entirely.
Krypterede mails bliver stort set ikke brugt af "almindelige mennesker", så du har højst sandsynligt aldrig modtaget en krypteret email. Hvis du havde, skulle du "gøre noget".
Kryptering af email er baseret på PKI, hvilket grundlæggende drejer sig om at man taler om to nøgler kaldet et nøglepar. En privat og en offentlig.
Man kan med eksempelvis GPG generere et sådant nøglepar. Den offentlige nøgle giver du så til folk der gerne vil skrive krypteret til dig. De krypterer så beskeden med din offentlige nøgle og når først beskeden er krypteret kan den kun dekrypteres med din private nøgle.
Det er derfor ekstremt vigtigt at det er dig og kun dig der har adgang til din private nøgle, da alle med adgang til den private nøgle kan dekryptere beskeden.
På samme måde kan man, uden at kryptere indholdet, verificere at det er dig der har sendt beskeden. Du bruger din private nøgle til at signere beskeden og jeg kan med din offentlige nøgle verificere at det er dig.
Den store udfordring har traditionelt været at finde ud hvordan vi udveksler offentlige nøgler, for hvordan kan jeg vide at en given offentlig nøgle virkelig er din? For at gøre det sikkert bliver man nødt til at mødes fysisk, da man jo ellers står med en slags "hønen og ægget" problem.
Netop det med at den private nøgle kun skal være kendt af den der signerer beskeden er i øvrigt grunden til at NemID ikke kan klacificeres som en digital signatur. Lidt off topic, men kunne ikke lade være med at nævne det.
Jeg er langt fra ekspert i kryptografi og det er et virkelig "langhåret" emne, men jeg håber det nogenlunde forklarede det. :-)
>can you post a short explanation or link to explanation of Owner Trust and the different levels?
Here you go:
https://www.gnupg.org/gph/en/manual.html#AEN335
https://en.wikipedia.org/wiki/Web_of_trust
Here's an alternate procedure using Kleopatra and signing the Tails key with your own key:
You need to certify the Tails signing key with your own key.
If you do not have your own PGP key, then create one first before proceeding:
File > New Certificate
Select "Create a personal OpenPGP key pair".
Use a fake name and fake email address.
Hit Next.
Hit Create Key.
Enter a password to protect your key.
Hit Finish.
Select "All Certificates" from the drop down on the right hand side of the "Find" text entry area.
Under "Name" there should be a key listed as "Tails developers (offline long-term identity key)".
Right click on that key and select "Certificate Details".
Make sure the key fingerprint is as follows
Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F
Once you have verified the key fingerprint, right click on the key again and select "Certify Certificate".
Check mark the Tails key.
Check mark "I have verified the fingerprint".
Hit Next.
Select which of your keys you want to sign it with.
Select "Certify for myself".
Hit "Certify".
Enter the passphrase for your key.
Hit Finish.
Right click on the Tails key again and select "Change Owner Trust".
Select "I believe checks are very accurate".
Hit File on the top menu bar and select "Decrypt/Verify Files".
Drill down to the directory where both the Tails ISO and the Tails ISO signature (.sig) files are located.
Select either one.
Hit "Decrypt/Verify".
You should get a green "Signature is valid" message.
(Because of a bug in Kleopatra, it will still say "unknown certificate": https://bugs.kde.org/show_bug.cgi?id=287145)
Interesting I haven't heard much of 3072-bit keys, only 1024/2048/4096. 2048 is the standard and by far most common. 2048 is going to have better compatibility and less CPU usage. It depends on what your clients are like and what you want to cater to. With certificate compatibility/strength there is a trade off, and you need to decide which is more important. I would love to hear some other responses on this issue.
A few links stating that there are benefits but they are not worth it most of the time:
http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits
https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096