My fundamental recommendation is that you should encrypt these files, n-o-t with any(!) sort of "passphrase," but with "keys."

You encrypt the file using your key, and you also provide the public key(s) of the one-or-more recipients who are to be authorized to decrypt it. Any of them can now decrypt the contents ... as can you ... but no one else can.

The process of preparing the material and encrypting it is trivial, as is the process, on their side, of retrieving what you sent. All they need is their private key, which only they possess.

There is no need for further security: the certificates provide a level of entropy that no password can begin to match. (Up to 4,096 bits' worth, at this writing.) The encryption/decryption sequence is easy for the intended parties, and effectively impossible for anyone and everyone else. All that you have to do is to make sure that the private keys do remain private.

All that monkey-business with passphrases and KeepassX? You simply don't need to bother. This is much stronger. (As well as, "easy.")

I'll have to look more into certificates and how their implemented.. But I heard that a 3072-bit asymmetric key is equal to a 128-bit symmetric key, and also asymmetric algorithms are susceptible to Shor's algorithm (quantum computing).

Yes. RSA 3072 bit keys give approximately the same security as a 128 bit symmetric key, that's why you don't use 128 bit RSA keys.

Yes, Shor's algorithm is effective against RSA and ECC. But building a quantum computer capable of breaking keys larger than 2 or 3 bits is an open research topic. There are some asymmetric algorithms that are not susceptible to Shor's algorithm, but they don't see much use currently because they are slow and require large keys, see Post quantum cryptography.

But also ...(!) in this regard, "I would but beg you to climb down from the mountain-top of The Theoretical, and instead to remain focused upon the Enormous Valley that pragmatically applies to you!"

From your perspective, you simply want "to do (much) better than Passwords."

And it so happens that certificates, as presently implemented by PGP®/GPG, already beats the socks off this approach.

You can today send an encrypted file "to multiple, yet specified(!) recipients," without having to pre-suppose the existence of any sort of "shared secret." (i.e. a "puny password.")

Instead, you need only possess, for each intended recipient, a "public thing" (freely given to you by each recipient), that is derived from some "private thing" that, in fact, you never possess. You send your encrypted message to them in confidence, because you are (somehow ...) confident that only they possess the one-and-only existing copy of that "private thing," and that only the possessor of that very "private thing" will be able to decrypt your message.

I-f you can be sufficiently-confident of this, then: "this beats the holy-Hell out of 'Mere Passwords.'"

The MAX you can usually request though is a 4096-key, and /dev/random must be used to improve entropy (because by itself it's not sufficient)



Yes im aware of MARS, Serpent, Two-Fish, RC6 and I may try those out depending how slow they are..

That's not what Einstein would of said.

But there's still a shared key to get around that distance limitation, and the fact that this key is used to make communicating over long distances convenient, means that it must be sacrificing security somewhere (because security is not convenient).

Usually, yes.

Huh? I have no idea what you're trying to say.

Those are all symmetric algorithms, so they don't replace RSA or ECC.

No, there is no "shared key!"

Conceptually, he message is enciphered using a randomly-chosen symmetric key that is generated by the software and known only to it. That key is then enciphered using the public key of each intended recipient.

Thus, the message can be securely retrieved by the possessor of the private key corresponding to any of these public keys. For those people, decrypting the message is easy and convenient. For anyone else, it is impossible.

"Shared Secrets" of any kind can never remain secret. But, each person can be issued an individual badge that is possessed only by them and which uniquely identifies them. If you possess one of the specific magickal amulets dictated by the sender of the message, the envelope becomes transparent and you can read the contents of the message. Your right to access the message is determined by what you possess, not what you "know."

gpg --gen-key (which generates a key pair) has you use /dev/random to "gain enough entropy" which I think is due to the fact that RSA by itself does not have enough entropy, so it must use /dev/random..



Well noted thank you.

The definition that I have is (and I apologize if this irrelevant, im a noobie) that key agreement schemes use the Diffie-Hellman algorithm because it uses the same shared key without a key exchange, which is good cause when communicating over long distances (otherwise if a shared key is not used then the recipient of the message would have to have knowledge of the key-cipher used to encrypt the message, which means a key-exchange would have to take place; and a key-exchange is not feasible when communicating over long distances). So the way PKI works is that both people have a private key, with one sending the base, public key, and prime to the other. Then the other sends their public key while generating a shared key..

https://www.youtube.com/watch?v=GSIDS_lvRv4 (short Youtube vid on what im talking about)

I haven't generated a key recently, but I would expect gpg to use /dev/random or equivalent APIs of the OS it's running on. I don't know what "has you use /dev/random" could possibly mean.

An algorithm, like RSA, cannot have or lack entropy, so this doesn't make any sense.

/dev/random is when you move your mouse and type on the keyboard randomly to increase entropy


You're right after a quick search I found it just needs entropy to generate a key pair.. I guess I meant asymmetric encryption technologies in general..

Oh that. That's mostly to make you feel better about your keys.
Some fun reading: https://www.2uo.de/myths-about-urandom/

Generating symmetric keys requires as much entropy as asymmetric ones.

At the risk of sounding "pedantic" at this point . . .

The specific "use of GPG" that I had in mind is one that allows you to encrypt a file in such a way that it can be decrypted by (only!!) those specific parties who were in possession of "the private keys which correspond to" a collection of public-keys which were (of course ...) known to the sender.

The sender generates a random symmetric-cipher key that is presumed to be "un-guessable." The sender then provides that key to each of the intended recipients, protected by each one's public key, so that only the corresponding private key can be used to retrieve it.

The entire notion of "key exchange," then, is entirely irrelevant. O ne party possesses the entire secret. The other party does not ... unless(!) they are able to decrypt the portion of the message which gives it to them.

Thanks alot for the info ill have to do more research on the topic