# Tag Info

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, ...

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 ... 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 ... 7 There's a problem with boundaries here; how much "complication" is allowed? I could argue that SHA-2 is a complication of SHA-1 because they both use a Merkle-Damgård construction and have other similar elements. Then again, they are significantly different internally. On the other hand the addition of a single bitwise rotation did make SHA-1 significantly ... 6 Anye$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 ... 5 RSA is and was specified by the PKCS#1 specifications of RSA laboratories. PKCS are the "Public Key Cryptography Standards" by RSA Laboratories, now part of EMC2. The RSA PKCS#1 v1.5 is the lowest publicly released version of RSA by RSA labs that can currently be downloaded. Version 1.0 to 1.4 are working drafts as specified in the PKCS#1 documents ... 4 If you have an error in a cipher text block you can generally represent this as: $$C'=C\oplus\Delta$$ Now if you try to decrypt this block using the previous ciphertext block$IV$as IV you get$P'=IV\oplus D_K(C\oplus\Delta)$which is completely unrelated to$P=IV\oplus D_K(C)$assuming the block cipher acts as a pseudo-random permutation. As the input ... 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 ... 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 ... 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 ... 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 ... 3 Like Ricky Demer suggested, qeadzcwrsfxv is a common finger pattern (similar to something like asdfghjk). The second example falls in the pattern of: Take dictionary word (besancon is the name of a city), uppercase the first letter and add a couple of digits after it (usually 123, 321, 007 or a year like 1998). Then a couple of rule-based alterations are ... 3 This approach will work, but there's another approach I want you to suggest. As for why it's secure (or better the ways to attack): Break the elliptic curve discrete logarithm problem. If you can do this you can just grab the first address out of your addresses, solve for the private key and derive all subsequent ones. This is generally considered ... 3 As I understand, your question is about using an involutive function$F$as a block cipher. This function is constructed as$F(x) = D(P(E(x)))$, for some (let's assume secure) block cipher represented by$(E, D)$. I will assume the encryption and decryption keys are equal such that the same holds for$F$. Below is a generic attack that only uses the ... 3 By fixing the first byte of both the private and the public key you actually reduce the key space by about 16 bits, because only about one in$2^{16}$key-pairs has that property – as you notice. (If there is no way to exploit the restriction on both keys at the same time, you may lose less security but I would assume the worst.) Doing this is fine, unless ... 2 The output of the block cipher is used as the new key, and also passed to the "output block" function, which is referenced in the NIST document as$B^m_R$. The purpose of the IV$R$and the function$B^m_R$is to reduce the output to a smaller size in a manner that hides the true output of$f\$. Too large an output allows key recovery. The output of this ...

2

No, not all encryption tools are made equal. Even when using the same cryptosystem, say AES-256, a tool's choice of cipher mode, how to generate AAD if present, how to generate IV, how to generate key, and the quality of the random source all affect quality. The quality of cryptography engineering is the major deciding factor at that point and it is tricky ...

2

If I understand your query correctly then you mean that if the decryption is successful then the original message should be destroyed. That said you can do this in such a way that once the password entered is correct the Plain Text should be displayed and the cipher text should be altered beyond recovery. You can write a program to do that. There are some ...

2

Consider that I, as an attacker, suspects what you're sending in your secret messages. If what you propose were possible, then I could know your plaintext by comparing my encryption of what I thought you were sending to what you actually sent, and brute for variations until I could confirm what you had sent. This would be VERY bad. Therefore, I assume you ...

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, ...

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

To remain immunized from cryptanalysis One-Time-Pad must be encoded with a perfectly random key, which is not easy to do. Any pattern in the key will make its corresponding plausible plaintext into unlikely to be a randomized result. For example, if you encrypt your message P with a key K=0101010101010..., to get a ciphertext C, then, a cryptanalyst will ...

1

Yes, this is known as convergent encryption. The usual way to do it is content hash keying, where you hash the plaintext, then use that hash as a key for deterministic symmetric encryption. You get authentication "for free" by checking that the hash matches, though that means the ciphertext is unauthenticated and you probably want to avoid modes like CBC ...

1

I'm to answer your question and say that yes, complicating an algorithm can make it secure. But I'm also going to define complicate the way I want to define it, not necessarily the way you want to define it. The Luby-Rackoff theorem tells us that if we have a good enough round function, you can make a secure cipher with enough rounds. In specific, if your ...

1

You wrote in the comments: Thanks. Beyond allowing you to select an encryption algorithm, Comodo Backup offers no details or options. I did find some additional information, which I'm adding to the original post. After looking at the list provided: Mentioning XOR and DES as valid choices (even if not marked as "strong or higher") is a terrible design ...

1

Or in other words, is keeping initialized cipher in memory basically equal to keeping key in memory? In the case of AES, yes, every time you encrypt (or decrypt) another block of data you need the key (or equivalent information, like the round keys), so the cipher instance must have it somewhere. Other ciphers (like Keccak's AE mode) may allow ...

1

Complicating an Algorithm will not make it more secure. The better approach is to avoid the "Security by Obscurity" approach, assume that your algorithm is publicly accessible. Focus instead on the security of the key such as making sure your code/algorithm during processing doesn't leak important clues about the key.

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