# Tag Info

0

If you use a deterministic encryption algorithm (so that you can actually verify passwords without the private key) it basically works like a backdoored hash. An attacker will be able to use a brute force or dictionary attack normally. One obvious problem with any reversible encryption is that it reveals (at least something about) the password length. (E.g. ...

2

This is a really bad (and somewhat pointless) idea (if you do it on your own), because it provides less security than standard hashing and should only be considered if password escrow is a necessary feature. If you don't need the password escrow (= recover the password using the heavily secured airgapped private key) you can simply password-hash the password ...

18

The answer is in the source, file sshrsag.c, line 9: #define RSA_EXPONENT 37 /* we like this prime */ This value $e=37$ matches the conditions for a reasonable fixed RSA public exponent: $e$ is odd, $e$ is at least $3$, $e$ is reasonably small. The later condition is good for speed of operations involving the public key (encryption, ...

6

Any $e$ such that $\gcd(e, (p-1)(q-1)) = 1$ will do. There is no need for it to be in the set $\{3,17,65537\}$; these last numbers are chosen for speed of encryption, mostly (two set bits leads to faster computation of modular exponentation), and these numbers happen to be prime, so the condiiton is easily checked. One often encounters other $e$, but many ...

3

The adversary clearly can do that. But if the adversary wins with this strategy, then the scheme in question cannot even be CPA secure and is far away from reaching the goal desired from CCA security. Recall, CCA security requires that even having access to a decryption oracle (for any ciphertext but the challenge ciphertext) does not help the adversary.

2

Yes, asymmetric encryption is slow compared to symmetric encryption. With symmetric ciphers, encryption and decryption speed can be several gigabytes per seconds on a common PC core; see these benchmarks. With RSA encryption, on comparable hardware, we are talking tens of thousands encryptions per second, and only few hundreds of decryption per seconds, ...

0

Take a look at the ECDAA protocols. They are implemented in the Trusted Platform Module (TPM 2.0). ECDAA is based on pairings over elliptic curves. In contrast to Idemix, they have the benefit of being far more efficient. In contrast to U-Prove, they have the benefit to be multi-show unlinkable.

3

Yes, RSA is an example of a cryptosystem where this is possible. The message is encrypted using the recipient's public key only and even the sender could not decrypt it. However, in the comments you mention that you would like to minimize storage requirements. RSA would require e.g. 2048 bits for just the message. In comparison, with ECIES sending a ...

2

Generate a random symmetric key (for example an AES key). We will use it only once for this transmission, and call it the session key. encrypt the session key with the public key encrypt the message with the session key forget the session key transmit the two encrypted message to the recipient Since you are using a whole new encryption key for every ...

-1

well I sort of came up with this method , I dont know whether most people already know this or not. For every example in my text book this method has worked d= [ɸ(n) * (y)]+1 divided by e. here y = 1 , 2 ... eg p=5 , q=11 e=3 n will be 56 and ɸ(n) = 40 d= (40 * 1) +1 / 3 = 41/3 = 13.66 --- but this is not an whole number so d= (40 ...

1

See https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29 Under Key Generation: Compute n = pq. n is used as the modulus for both the public and private keys. Its length, usually expressed in bits, is the key length.

1

This sounds like Kerberos. ( https://en.wikipedia.org/wiki/Kerberos_%28protocol%29 ) In any case, you didn't mention, but it would seem quite important, how long are the generated auth tokens valid for, or how would you expire one. There is no such thing (IMHO) as permanent/indefinite authorization--if you believe otherwise, you should not be doing ...

3

In asymmetric crypto including RSA, we ALWAYS encrypt with the public key, and decrypt with the private key (NEVER the other way around). In the question, what's wanted is to sign with the private key, not encrypt. And that's enough to solve the whole problem, since RSA signature schemes exposed in BouncyCastle or the Java crypto API allow to sign data of ...

0

I have seen this before in Java. Java's BigInteger class requires and generates binary data as signed little-endian. If the high bit of the first byte is set, the whole number is interpreted as negative. In order to represent a 1024-bit number in which bit 1023 is set, it's therefore needed to add a 00 byte to the beginning, because otherwise, it'd be ...

8

You are looking at the ASN.1 encoding of private (and public) keys; the 00 values you see are an artifact of how ASN.1 encodes integers. ASN.1 is a method for describing data structures, and has ways to represents all sorts of data types. It wasn't designed with public keys (or cryptography) in mind; it was intended for more general use, initially ...

0

The entire setting is highly unrealistic. You assume, your motes can do public key cryptography. The motes know the public key of the base. Reasonably sized public keys (non-ECC crypto, like RSA, ElGamal, etc.) are at least 150 byte (1200 bit), and anything below 100 byte is considered broken today. The base has a whitelist with the public keys of the ...

3

The requirement was introduced in IUT Recommendation X.509 (November 1993), informative appendix D.5.2: It must be ensured that e > log2(n). If not, then the simple operation of taking the integer eth root of a ciphertext block will disclose the plaintext. This advice was removed in the 2000 edition of the standard. It is arguably misguided, and at the ...

0

You don't really need to authenticate the base to the mote before transmission to ensure confidentiality, since the data will be encrypted to its key. The real reason you need it is to prevent an attacker from tricking the mote into thinking it's reported already and causing data loss. To prevent replay, storage is fundamentally required. The problem is the ...

4

This protocol doesn't authenticate the mote at all. Consider this attack: Mote B sends a 'hello' message to Base. This message contains the ID# of Mote A and a random nonce [R] (HW generated) encrypted by the base's public key. Base decrypts the 'hello' and verifies the ID# against a whitelist. Base sends an 'ack' message. This message contains some ...

0

How they work Public and private keys work as follows. Every party who wants to communicate with others generates a private key which they keep secret. From that private key, they derive a public key, which they publish for anyone to see. For example, if we have three agents, Alice, Bob, and Charlie, they will all have a secret key S_A, S_B, and S_C and a ...

1

The size of the public key depends on the elliptic curve used. Any private key will produce a point on the curve, which is the same size – approximately 256 bits for 256-bit curves, for example. Random numbers from a small range could be insecure, however. The secure way to generate the private key is to take it from the range $[1, l-1]$, where $l$ is the ...

1

MIGJAoGBAKv4...................3VpXAgMBAAE= 30818902818100 ABF8... ...DD5A57 0203010001 7 5 Overhead & public exponent are 7 + 5 = 12 bytes. You have a 1024 bit modulus = 128 bytes. So a correct encoding would be 12 + 128 = 140 bytes, requiring ceil(140 / 3) = 47 * 4 = 188 base 64 characters. You however ...

0

Now that of course gets more complicated with bigger numbers too, but still quite easy/fast. So basically if those numbers are not primes, that you can just split up $n$ as much as possible and from there you have an easier way to find $p$ and $q$. If both are primes you have to try values for $p$ and $q$ until you find exactly the right values.

0

For the problem of determining the base ($m$), the problem is that you don't have enough information. For any valid value of $e$, there is a matching value $m$ that encrypts to the same $c$; specifically, $m = c^d \mod n$. Because there are many, many possible answers, there's no way to determine this, unless the value of $e$ is very small or predictable, ...

0

Assume the public key $e$ is not known, how difficult would it be to guess the public key using $n$, $\phi$, $p$ and $q$? $e$ can be chosen completely arbitrary and independently of the modulus and related variables ($\phi,p,q$). You can't learn anything about $e$ (assuming $d$ isn't given) only with the modulus given. Assuming we have $c_1$, $c_1 ... 1 To expand on Ricky's comment, assuming Alice and Bob are the only participants, they can use an identity-based encryption scheme where Alice also acts as the trusted third-party ("Private Key Generator" in the Wikipedia article). Namely: Alice puts on her PKG hat, and generates the public parameters of the system and a secret which will be used later. ... 4 The method mentioned in the answer by Maarten will allow you to reduce the private key size for any public key algorithm by regenerating the key from a random seed, each time you need it. The drawback is the performance. Each time you need to use the key you need to spend as much CPU time for regenerating the key as you used for generating it the first ... 15 If we want to compact an existing RSA private key expressed as$(N,e,d,p,q,d_p,d_q,q_\text{inv})$, we can reduce it to$(e,p,q)$and easily recompute the rest as:$\begin{align} N&=p\cdot q\\ d&=e^{-1}\bmod\operatorname{lcm}(p-1,q-1)\;\text{ or }\;d=e^{-1}\bmod((p-1)\cdot(q-1))\\ d_p&=d\bmod(p-1)\;\text{ or equivalently }\;d_p=e^{-1}\bmod(p-1)\\ ...

12

You can use a seed to start a PRNG. Then you can use that PRNG to generate the two (or more) primes required to generate the key pair. Now if you save that seed you can regenerate the key pair, which means you don't have the store the modulus, CRT components or private exponent. So yes, it is possible to reduce the size, but this approach does have ...

0

I've created an example in Javascript which I think solves my problem. Any tips for updates to make it even more simple are welcome :-) https://github.com/kubrickology/Bitcoin-explained/blob/master/RSA.js

3

Proofs of Storage (PoS) are challenge-response protocols that allow a client to verify that a server is truthfully storing a file. See this paper from Ateniese, Kamara and Katz for an example of PoS. The basic idea is explained in this quote from that paper: Viewing the file $\vec f$ as an $n$-dimensional vector, the client begins by tagging each ...

0

You could use message specific keys, which encrypt the messages themselves. Once a secret key has been established you can encrypt the message specific keys with it and send them over in a new message (with meta-data) to user B. You should of course have some method of storing the encrypted messages somewhere for this to work.

Top 50 recent answers are included