I would like to use an asymmetric encryption process without making the "public" key really public.
My world contains 3 actors : A, B, C and a public message bank.
I want A to be the only one able to encrypt (and decrypt) short messages in the bank (for example AES keys), and I want A to be able to later chose who gains access to the encrypted data in the bank without the need to re-encrypt or add messages to the bank.
It would go like this:
A generates a key pair with RSA : (p1,p2), p1 being the "private" key (used here only for encryption) and p2 being the "public" key (used here only for decryption)
A encrypts the messages with p1 and stores them in the public bank : A, B and C can access the stored encrypted messages. For now, only A can decrypt the messages.
Later, A wants B (and only B) to be able to read the messages (but not to write more messages in his name in the bank), so he gives p2 to B in some secure way.
Is it a correct use of the RSA algorithm ? Does RSA ensure that B and C will not be able to read M without the "public" key p2?
Why does the vocabulary around asymmetric encryption seem to deter me from doing so? Is there a better way to achieve the same functionality ?
Any advice would be much appreciated
EDIT :
I know that I'm not using the RSA protocol in the usual way (public key encryption/ private key decryption), but the math behind it (as I understand it) should allow working the other way around.
Related
Recently while learning Backend development (Node, Express, MongoDB), I discovered the crypto-js library. According to the docs, we can use the following code to encrypt a message using the AES Encryption -
const ciphertext = CryptoJS.AES.encrypt('my message', 'secret key 123').toString();
However, as I'm new to cryptography, the difference between an encryption algorithm and a secret key is not very clear to me.
I have a message, and I can use the AES encryption algorithm to encrypt/decrypt it. Same way, I can use the AES encryption algorithm to decrypt the message as well. Hence, I don't understand how does a secret key fit in here? How exactly do an encryption algorithm and a secret key work in tandem to secure a message?
I have gone through numerous videos, blogs, StackOverflow posts, etc. on the internet, however, I couldn't understand it completely through all the complex crypto jargon. I do have a faint idea, which I'll describe below with the help of Ceaser's cipher.
In Ceaser's Cipher, what I've understood is that the technique of shifting letters by a certain number (A shifted by 4 places is E) is the encryption algorithm, and the certain number (4) is the secret key.
Can somebody please tell me if I'm correct?
If I'm correct, can you please tell me how exactly this translates in the case of the AES encryption mentioned in the beginning?
If I'm not correct, can anyone explain this with the help of a simple analogy? Please try to minimize the use of crypto jargon, as otherwise I'll get lost again.
The algorithm is a series of steps that happen in processing the data with the secret key to produce the encrypted data.
There are two inputs into the algorithm - the key and the initial data. The algorithm takes those two inputs and produces the encrypted output.
+---------+ +---------+
| Key | | Data |
+---------+ +---------+
\ /
\ /
\ /
\ /
\ /
+-----------+
| Algorithm |
+-----------+
|
+-----------+
| Encrypted |
| Result |
+-----------+
The key and the data are separate from the algorithm. If you change either of them, you will get a different encrypted result without changing the algorithm.
In your example of the very simple Caesar Cipher, the algorithm is that each character in the input is going to be replaced by another character (a substitution cipher) that is offset in the alphabet by some amount.
The key would be what the amount is. So, if the key is 1, then a is replaced by b and b is replaced by c and so on. The code for the algorithm can be written to accept the key as an input parameter or function argument and the algorithm code does not have to be rewritten for a different key. The key is applied to the input data by the algorithm programmatically to produced the result. The same algorithm code works with all the different keys you can pass it.
Can somebody please tell me if I'm correct [in understanding the algorithm and key in the Caesar Cipher]?
Yes, your understanding of that is correct.
If I'm correct, can you please tell me how exactly this translates in the case of the AES encryption mentioned in the beginning?
The AES encryption is a much more complicated algorithm that again accepts input data and a key. In this case, the key is a block of data itself, not just a single number. If you want to know more about how it works, you can find many articles on the web about it so it's probably better to read those than try to repeat all that here. Here's one article: What is AES Encryption and How Does It Work?.
Note, you generally do not need to know how a given encryption algorithm works in order to use it successfully. You do need to know how secure it is, what kind of keys are required, what kind of output it generates and how you decrypt it. But, you don't need to know the details of how the algorithm works. And, you need to select the right type of algorithm (for example, symmetric encryption with the same key used for encryption and description vs. asymmetric encryption such as public key/private key pairs) because this determines how you generate/manage/share secrets.
In your code example:
const ciphertext = CryptoJS.AES.encrypt('my message', 'secret key 123').toString();
CryptoJS.AES.encrypt is a function that implements the algorithm. It accepts two arguments. The first argument is the data you want encrypted. The second argument is a key string where all the data in the key is used in the encryption and the key will need to be supplied again in order to descrypt the data.
The result of the call to CryptoJS.AES.encrypt() is a buffer of data.
As it stands, I have written a python3 project to encrypt a file (using AES) and a public/private key system (RSA) to encrypt the AES key.
My current predicament is as follows, what is the best approach to get the encrypted AES key to the recipient ? My program does NOT depend on the medium for sending of the files, rather just the files are securely encrypted. In other words, once a user chooses a public key of the recipient, there is no peer-to-peer communication.
Is naming the file the RSA encrypted AES key a bad idea ?
I dont have extensive knowledge of cryptography as such, so any suggestions are welcome
If you know the recipient public RSA key you can use RSA-KEM (KEM : Key Encapsulation Mechanism). RSA-KEM for a single recipient with AES-GCM simply as follows;
The Sender;
First generate a x in [2..n-1] uniformly randomly, n is the RSA modulus.
Use a Key Derivation Function (KDF) on x,
key= KDF(x)
for AES 128,192, or 256-bit depending on your need. Prefer 256.
Encrypt the x,
c = x^c mod n
Encrypt the message with AES-GCM generate an IV and
(IV,ciphertext,tag) = AES-GCM-Enc(IV,message, key)
Send (c,(IV,ciphertext,tag))
The receiver;
To get x, They are using their private exponent d,
x = c^d mod n
Uses the same (KDF) on x to derive same AES key,
key= KDF(x)
Decrypts the message with AES-GCM
message = AES-GCM-Dec(IV,ciphertext,tag, key)
Note 1: This is actually a composition of a KEM and a DEM (data encapsulation mechanism; an authenticated cipher serves as a DEM). This provides the standard of IND-CCA2/NM-CCA2—ciphertext indistinguishability and nonmalleability under adaptive chosen-ciphertext attack. That is the minimum requirement for modern Cryptography.
Note 2: If you want to send the key itself as you described, to prevent the attacks on textbook RSA, you will need a padding scheme like OAEP or PKCS#v1.5. RSA-KEM eliminates this by using the full modulus as a message.
Note 3: The above described RSA-KEM work for a single-user case. RSA-KEM for multiple users will fall into Håstad's broadcast attack. Instead use RSAES-OAEP, this makes it safe for multiple recipients with the same x encrypted for different recipients. This will make it very useful to send the message multiple recipients instead of creating a new x for every recipient and encrypting the message for each derived key (as PGP/GPG does).
Decode Text encrypted with DH coded with Caesar Cipher.
We have to decode following text: FKXSQBQZACKFAHRSCAN DFYZSYQBSFN.
I have tried to "guess" the private Key for Alice with a for loop and think I got the right one but now I'm stuck.
p,g and A are given.
p = 23
g = 15
A = 6 #exchangeKey Alice
I think the problem could be that I don't know how the text is coded. Did the teacher use an array like?:
alphabet = ["A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"]
Or did she use the ASCII table.
But is it even possible to decode this text without any information about "Bob".
My research brought only information about MITM attacks where the hacker got p,g,A and B
Get Alicekey
for getkeyalice in range(p):
if (g**getkeyalice)%p == A:
keyalice = getkeyalice
Decode
for char in message:
#index=(alphabet.index(char)-j)
#decryptedlst.append(alphabet[index])
decryptedlst.append(chr(ord(char)-i))
decrypted = ''.join(decryptedlst)
print("decrypted message:\t"+str(decrypted))
I'm looking for the decryption key. I don't expect this should be a very high number. But even bruteforcing all numbers from 1-4096 didn't help. So back to the top.... perhaps the kind of decryption I'm using is different to the encryption of the teacher.
This problem can not be resolved due to a lack of input.
Even if you can easily brute-force Alice's private key, that is 14 (15¹⁴[23]≡6[23]), you have not any information about Bob's choice of key values, so you have no information that could help you find the DH shared secret between Alice and Bob. This is because the shared secret depends both on informations chosen from Alice and on informations chosen by Bob. Therefore, you can not cryptanalyze this problem.
I am relatively new to PKI, certificates and all related stuff.
As far as I understand in public-key cryptography one encrypt with a public key and decrypt with a private key. Only one private key can correspond to any public key but the opposite is not true. Is it correct? Or is it one to one mapping?
So, the way digital signature works is that the content of a certificate is hashed and then "signed" with a private key. The signature is verified then with the corresponding public key.
So, here is where I get confused. What is the difference between encrypting a message with a public key and signing a message digest with a private key?
Difference between Message Encryption and Signing
I think information security objectives are essential to realize the difference between message encryption and signing. To define a few objectives:
Confidentiality: keeping information secret from unauthorized parties.
Data integrity: ensuring that information has not been altered by unauthorized means.
Message authentication (data origin authentication): corroborating
the information source.
Non-repudiation: preventing the denial of previous actions.
Message encryption provides confidentiality.
Message signing binds the identity of the message source to this message. It ensures data integrity, message authentication, and non-repudiation altogether.
I find the fourth objective, non-repudiation, I find it distinguishing so please allow me to elaborate on it. Alice could at some point in time deny having signed a message or Bob could falsely claim that a message signature was produced by Alice. A digital signature permits an unbiased trusted third party (agreed upon in advance) to resolve the dispute without requiring access to the signers' secret information (private keys).
The digital signature system you mention in your question is referred to as digital signature from reversible public-key encryption. All in all, any digital signature scheme should have the following properties:
It is easy to compute by the signer.
It is easy to verify by anyone.
It is secure from forgery until it is no longer needed (the signature lifespan).
As for encryption systems, Kerckhoffs defined a set of requirements that are still, for the most part, useful today. Please read up on the wiki.
Types of Functions Used in Cryptography
Regarding the types of functions that are used for key generation and encryption/decryption, let's again give a few definitions:
One-to-one function: A function f: X -> Y is one-to-one if each element in Y is the image of at most one element in X.
Onto function: A function f: X -> Y is onto if each element in Y is the image of at least one element in X.
Bijection function: A bijection is both one-to-one and onto.
One-way function: A function f: X -> Y is one-way if f(x) is easy to compute for all elements in X but for all elements y in Y it is computationally infeasible to find any x such that f(x) = y.
Trapdoor one-way function: It is a one-way function f: X -> Y in which the knowledge of extra information (trapdoor information) makes it feasible to find for any y in Y, an x in X such that f(x) = y.
A bijection is used as the tool for encrypting messages and the inverse bijection is used to decrypt.
A trapdoor one-way function is used for key pair generation in public-key cryptosystems and digital signature schemes.
A Trapdoor Concrete Example
In RSA, the public key is (e,n) where n =pq and p and q are two large, distinct prime numbers . e is randomly chosen in the range 1 < e < (p - 1)(q - 1). Given the knowledge of (p - 1)(q - 1), the unique private key d is obtained through the application of the extended Euclidean algorithm. It is a trapdoor one-way function that enables us to obtain d from (e,n).
If you don't know (p - 1)(q - 1) and still would like to discover d, then you need to factor n. If p and q are large and carefully chosen, factoring n should be intractable. This is the RSA problem (RSAP).
But where is the trapdoor? As you may have noticed, the trapdoor is the factors of n. If you know these factors you can easily invert the one-way function and reveal d.
public keys encrypt, private keys decrypt for encryption and for digital signatures, it is the reverse.
Tip: Imagine public key as padlock and private key as key which opens the padlock.
Two of the best-known uses of public key cryptography or asymmetric cryptography are digital signature and Public key encryption. In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. Security depends on the secrecy of the private key.
To use a Digital Signature or Public key Encryption we must have a digital id or digital certificate or public key certificate or identity certificate. It is an electronic document used to prove the ownership of a public key.
Digital Signatures in which a message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as a signature is mathematically bound to the message it originally was made with, and verification will fail for practically any other message, no matter how similar to the original message. An analogy for digital signatures is the sealing of an envelope with a personal wax seal. The message can be opened by anyone, but the presence of the unique seal authenticates the sender.
Public Key Encryption in which a message is encrypted with a recipient's public key. The message cannot be decrypted by anyone who does not possess the matching private key, who is thus presumed to be the owner of that key and the person associated with the public key. This is used in an attempt to ensure confidentiality. An analogy to public key encryption is that of a locked mail box with a mail slot. The mail slot is exposed and accessible to the public – its location (the street address) is, in essence, the public key. Anyone knowing the street address can go to the door and drop a written message through the slot. However, only the person who possesses the key can open the mailbox and read the message.
img src
A Public Key Infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
img src
Authorities:
Registration Authority (RA), Certificate Authority (CA) and Validation Authority (VA)
Algorithms:
DES (Data Encryption Standard) and Triple DES (a stronger variant of DES), AES(Advanced Encryption Standard) are Symmetric key cryptosystems. Which uses the same key for encryption and decryption.
DSA(Digital Signature Algorithm) and RSA(Ron Rivest, Adi Shamir and Leonard Adleman) are public-key cryptosystems, which are widely used used for secure data transmission. DSA provide only digital signatures and RSA provide both digital signature and encryption.
Message Encryption makes the whole message unreadable to anyone but the owner of the corresponding private key.
When you sign a message, then it creates something like a checksum of the message content in combination with data from the key, which can be verified against a public key.
This does not make a message unreadable to anyone, but can verify that the message really originated from the sender and was not altered since.
Of course this requires you to trust the public key, but that is another story.
To your first question: AFAIK it is theoretically possible to create a public key collision, but highly unlikely.
Any private key has one public key and any public key has one private key its always one to one mapping.
Signing the message is only create a finger print for the message just to make sure that the content hasn't been altered, but it has no effect on the message it self and the message will never be encrypted.
While encrypting the message will do the encryption. you can encrypt a message and sign it at the same time.
As already mentioned in the other answers, public and private key are coupled with each other. Actually in many encryption context you have a pair of numbers with certain properties and can choose which you want to use as private and which as public key. Thus, there is a certain degree of uniqueness here. (Details may vary according to the algorithm in question.)
When talking about PKIs, though, you often do not consider public keys but certificates which essentially are bundles of information (issuer, subject, validity interval, usage constraints, ...) with a public key. When creating certificates, you of course can build different certificates for the same public key.
Thus, while private and public keys essentially are one-to-one, private keys and certificates may be one-to-many.
Maybe this is the cause of your one-to-one confusion.
Today I was doing some leisurely reading and stumbled upon Section 5.8 (on page 45) of Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) (NIST Special Publication 800-56A). I was very confused by this:
An Approved key derivation function
(KDF) shall be used to derive secret
keying material from a shared secret.
The output from a KDF shall only be
used for secret keying material, such
as a symmetric key used for data
encryption or message integrity, a
secret initialization vector, or a
master key that will be used to
generate other keys (possibly using a
different process). Nonsecret keying
material (such as a non-secret
initialization vector) shall not be
generated using the shared secret.
Now I'm no Alan Turing, but I thought that initialization vectors need not be kept secret. Under what circumstances would one want a "secret initialization vector?"
Thomas Pornin says that IVs are public and he seems well-versed in cryptography. Likewise with caf.
An initialization vector needs not be secret (it is not a key) but it needs not be public either (sender and receiver must know it, but it is not necessary that the Queen of England also knows it).
A typical key establishment protocol will result in both involve parties computing a piece of data which they, but only they, both know. With Diffie-Hellman (or any Elliptic Curve variant thereof), the said shared piece of data has a fixed length and they have no control over its value (they just both get the same seemingly random sequence of bits). In order to use that shared secret for symmetric encryption, they must derive that shared data into a sequence of bits of the appropriate length for whatever symmetric encryption algorithm they are about to use.
In a protocol in which you use a key establishment algorithm to obtain a shared secret between the sender and the receiver, and will use that secret to symmetrically encrypt a message (possibly a very long streamed message), it is possible to use the KDF to produce the key and the IV in one go. This is how it goes in, for instance, SSL: from the shared secret (called "pre-master secret" in the SSL spec) is computed a big block of derived secret data, which is then split into symmetric keys and initialization vectors for both directions of encryption. You could do otherwise, and, for instance, generate random IV and send them along with the encrypted data, instead of using an IV obtained through the KDF (that's how it goes in recent versions of TLS, the successor to SSL). Both strategies are equally valid (TLS uses external random IV because they want a fresh random IV for each "record" -- a packet of data within a TLS connection -- which is why using the KDF was not deemed appropriate anymore).
Well, consider that if two parties have the same cryptographic function, but don't have the same IV, they won't get the same results. So then, it seems like the proposal there is that the two parties get the same shared secret, and each generate, deterministically, an IV (that will be the same) and then they can communicate. That's just how I read it; but I've not actually read the document, and I'm not completely sure that my description is accurate; but it's how I'd start investigating.
IV is public or private, it doesn't matter
let's consider IV is known to attacker, now by looking at encrypted packet/data,
and knowledge of IV and no knowledge on encryption key, can he/she can guess about input data ? (think for a while)
let's go slightly backwards, let's say there is no IV in used in encryption
AES (input, K)= E1
Same input will always produce the same encrypted text.
Attacker can guess Key "K" by looking at encrypted text and some prior knowledge of input data(i.e. initial exchange of some protocols)
So, here is what IV helps. its added with input value , your encrypted text changes even for same input data.
i.e. AES (input, IV, K)= E1
Hence, attacker sees encrypted packets are different (even with same input data) and can't guess easily. (even having IV knowledge)
The starting value of the counter in CTR mode encryption can be thought of as an IV. If you make it secret, you end up with some amount of added security over the security granted by the key length of the cipher you're using. How much extra is hard to say, but not knowing it does increase the work required to figure out how to decrypt a given message.