# Tag Info

12

I've been suggested to digitally sign it, thus, I have my private key, and I ship my application with a public key, and the application then uses the public key to check the QR code As long as you can live with the requirements for RSA (signature size, computation), that sounds like an excellent idea. Am I encrypting the whole message using the private ...

9

There are known impossibility results regarding basis public-key cryptography on NP-complete problems. In this paper by Goldreich and Goldwasser they show that under common types of reductions, it is not possible to base public-key cryptography on NP-hardness.

6

Use DLIES, which is essentially Diffie-Hellman with an ephemeral sender key. Assuming you know the receiver's public key, that will cost no extra round trips. The sender does: (eph_sender_private, eph_sender_public) = Generate_Key_Pair() shared_key = SHA-512(Diffie-Hellman(receiver_public, eph_sender_private)) ciphertext = Encrypt(shared_key, message) ...

5

The formula at the heart of RSA is: $$x^{\lambda(n)} = 1 \pmod n$$ where $\lambda$ is the Carmichael function. In the case of two-prime RSA it's $\operatorname{lcm} (p - 1, q-1)$. $$m^{k \cdot \lambda(n)+1} = m \pmod n$$ We choose $d$ such that $e\cdot d = 1 \pmod {\lambda(n)}$. If $\operatorname{GCD}(e,\lambda(n)) = 1$ then there is exactly one solution ...

4

To your questions: You are not encrypting anything. Signing something with RSA is basically the same algorithm as decryption but some things are different (see below). No. You can generate one keypair and then use it for encryption, decryption, signing and verification. To help you with your task: Getting this right is not easy. If you have no ...

3

Firstly, it's not co-prime to the modulus, so $\gcd(m,N)$ would be greater than $1$. Secondly, $N$ is the product of two (and only two) prime numbers $p$ and $q$, so if $\gcd(m,N)>1$, then you know $m$ is one of the factors (and prime factors) of $N$.

3

Yes, these are public parameters of the system. Note that NTRU is not implemented exactly this way any more. The most up-to-date current spec is EESS#1, which can be obtained from https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/doc/EESS1-v3.1.pdf.

3

It depends on the application if base 64 is being used to represent keys. Many applications that implement/use cryptography have been originally designed in a time where ASCII based communication was commonplace. If you would directly use BER / DER - a binary encodoing of parameters - then you had a high chance of losing data. For instance, you would not be ...

3

Base-64 is simply a way to represent binary data using the ASCII character set. It's used because a single base64 digit represents a whole number of bits (6 bits), where each decimal digit represents ~3.3 bits, which can make conversion a little tricky. Being able to represent more bits per digit also means its more space efficient than decimal. It takes ...

3

Comments already pointed out, that encryption and signing are not the same and should not be exchanged deliberately. Of course in practice specifically for RSA, not PKE in general, and only in the textbook variant (no padding), encrypt/decrypt are bascally the same operations as sign/verify: For all of them, you just do modular exponentiations; and the ...

3

This is only useful as a thought exercise, but Alice and Bob can do key exchange based only on the strength of AES or some other private cipher: Assumptions: doing $2^{40}$ operations will take "a while" but is doable; $2^{80}$ operations is out of the realm of possibility in a century. Alice can publish arbritary amounts of information which cannot be ...

3

Your idea lacks forward secrecy, which protocols like TLS often (in newer versions anyway) offer. Otherwise it is close to how such things are usually done. To get forward secrecy you would instead use an ephemeral Diffie-Hellman key exchange, which you would authenticate with the pre-shared public key (which would be a signing key, not an encryption key, ...

2

As no particular attack scenario has been given I'd add another, more high level option. When point-to-point transport security isn't supposed to be secure enough then you might consider end-to-end message security or application level security as well. The idea of TLS is that it protects messages from client to server. However, the client and the server ...

2

I do not have enough high reputation to comment so I am writing here. I have also looked at the paper so I would like to share my thoughts. I think that in order to understand whether the bit is in the "plain sight" one has to ask the question: Is it possible to recover the bit $y$ from the cipher g=y\oplus \bigoplus _{i=1}^{\alpha}\bigoplus_{a=1}^{\beta}{...

2

The size we speak of with regard to elliptic curves is the size of the field over which the elliptic curve is defined. This is not necessarily exactly the size of the private key. For example: Curve25519 is a 255-bit elliptic curve and has, effectively, 252-bit private keys, though they are usually encoded as 256-bit values with four fixed bits. Public keys ...

2

There is no way to know what the authors of that paper even did. They say they used Python, but mention no libraries. If it is their own implementation of those algorithms in Python, it may tell you next to nothing of the real world performance of optimized implementations those algorithms. Further, they say they encrypted files of 68-235 KB, but do not ...

2

I guess you are taking this information from this document. In Section 2.1 you can see a table with different sizes. In particular, a plaintext block (that is, an encoded message) has size $(n-k) \log_2 p$ bits, while a ciphertext has size $n \log_2 q$ bits. The explanation is simple: ciphertexts are actually polynomials of $n$ terms (since degree is $n-1$)...

1

An analogy might not be that helpful but an example for example with RSA signatures. RSA Signatures work like this: s = m^d mod N where s is the signature, m the message and d the private key. (See example below. Verification works like this: m' = s^e mod N where s is still the signature and e is the publicly known and trusted public key. If m' = m ...

1

Ok, here's a toy example (which really doesn't work) of a simple signature scheme, which you can use as an analogy of a real system: Suppose the signer Alice picks three integers $b, c, p$, and computes $a = b \times c \bmod p$. She then publishes $a, b, p$ as her public key, and keeps $c, p$ as her private key. Then, when Alice wants to sign a message $M$...

1

To decode from a public-key encoded message, you need the secret private key. Anyone else cannot do it. For the mathematical details how this is possible, you need to analyse the respective asymmetric cryptographic algorithms. There are several different asymmetrical encryption algorithms, including RSA and ElGamal, see the Wikipedia links for an ...

1

If you choose m such that gcd(m,N) #1, it implies that gcd(m,N)= p, one of the primes composing N, and in this case the code is broken. But you could always choose random numbers r, and calculate gcd(r,N), looking for the case its not equal 1. This is equivalent to factor N, and there are algorithms more efficient than this that factor N. On the contrary, if ...

1

That property lets a trusted n2-byte random string be enough to make the rest of public keys fit into n bytes. In particular, forward secrecy can be more efficient if the sender can store such a string, since the string can have been generated by the same party as generates the rest of the public keys. Also, if for random private keys and independent n2-...

1

No. ​ ​ ​ ​ Also, note that by hybrid encryption, ciphertext overhead will always be at most ​ ​ + poly(security_parameter) , ​ ​ no matter how long the message is. For IND-CPA of any public-key encryption scheme, or even symmetric encryption scheme with stateless encryption , ciphertexts for non-empty messages must be overwhelmingly likely to be ...

1

As an addition to the other answers: there are indeed multiple solutions available to you that do not rely on designing your own encryption-scheme and code. This is of importance as it is very easy to make mistakes on both the scheme and the implementation level. You might for example be able to take a certain (trusted) algorithm which should be safe and ...

1

How does one verify a key revocation? As Jon Callas already stated: you simply don’t. In case a different wording helps, here’s a quote related to the exact same question… https://lists.gnupg.org/pipermail/gnupg-users/2014-February/049100.html … On 02/19/2014 11:55 AM, Hauke Laging wrote: Am Di 18.02.2014, 23:19:33 schrieb Tadas ...

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