Tag Info

New answers tagged

2

No, usually you are required to use hybrid cryptography. ECB, CBC etc. are defined for block ciphers. Although you could possibly apply them to asymmetric cryptosystems, it would make little sense: performing sequential asymmetric cryptography is not efficient, block ciphers are much more efficient in general there will be a lot of overhead per block, ...


1

The real question isn't "Why doesn't Suite B use P-521?" It is, "Why doesn't Suite B use AES-192?" NSA were only interested in 192-bit security for Suite B, but they chose to use AES-256 because AES-192 wasn't widely supported. "In fact we had wanted to use AES -128 and AES-192, but a quick survey of AES implementations (hardware centric, I believe) ...


0

Because RSA with 512 bits is considered insecure for a fair amount of time yet, and 512 bit RSA primes are already breakable on an average new desktop computer in several weeks. For any kind of asymmetric encryption that is supposed to be secure, I would suggest a key size of at least 2048 bits, better 4096. Only for keys like session keys that time out ...


1

Theoretically there is no requirement for the public key to be hard to guess given the private key. The public key is assumed to be known by all parties, including the adversary, so there is usually not much point in making it hard to guess. In fact, the question depends a lot on what you define as the private and public keys: For example it is not ...


1

We all know that in a public key cryptosystem, given a public key it is extremely hard to compute private key from it. Is it the same case in reverse? Not in general. For example, in Diffie-Hellman the public key is just a constant raised to a private number, modulo another constant. In some elliptic curve algorithms, the public key is a curve ...


2

In practice, no. Firstly, RSA private keys are typically stored together with the public exponent. The standard definition includes the following information: RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p ...


2

Your javascript library linked to has no restrictions on key size. Many libraries out there that implement RSA will have a restriction on the key size. This is to make sure developers are following best practices as if the key size is too small, the security of the cipher is completely blown. It looks like the Java library you are using won't let you use key ...


0

The explanation of why the security parameter $k$ is given in the unary form of $1^k$ as mentioned at the second footnote at page 366 of Foundations of Cryptography Volume 2 is to allow a smooth transition to fully non-uniform formulations...Specifically $1^n$ indicates that the $n^{th}$ circuit is to be used.


2

I'm assuming you mean a base 64 encoded key file, since removing the newlines from a binary file would obviously break things. The RSA standards (e.g. RFC 2459) only define a binary representation for keys. In practice, like OpenPGP keys (RFC 4880), they are often encoded in base 64 using the otherwise obsolete PEM standards (RFC 1421). The PEM printable ...


2

I don't remember whether there is an official NIST publication on the topic, but there are definitely advantages to having a small set of possible key sizes. Contrasting RSA and DSA is instructive in this respect. A 170-bit $q$ wouldn't be less secure than a 160-bit $q$ if implemented correctly, but offering the choice is less secure. Security strength The ...


2

I will start with an example and then comment on a natural general way to achieve re-randomization: ElGamal: Let’s say we have a multiplicative written group $G$ (suitable for ElGamal) with public key $h=g^x$ and $g$ generates $G$ (or some prime order subgroup of $G$). Any library that implements ElGamal encryption can do the following, although there may ...


0

The question whether SSL/TLS is used for maintaining data confidentiality, is actually not as straight-forward as one might think. It depends. We might disregard the deprecated SSL cipher suites that provided authenticity and integrity with a NULL bulk encryption algorithm. Even if you only take the cipher suites that do encrypt the bulk contents into ...


2

The answer to the first question is both. TLS uses a custom PRF based on HMAC to generate symmetric and MAC keys from a shared secret. The shared secret is created during the asymmetric key exchange between client and server as part of the handshake. The PRF generates key material of a required length. That length is determined by the key sizes and the key ...


0

Your use case is specific enough that you may be able to avoid full signatures and use a one-way function directly. When publishing the data you can use as a public key the hash of a random value $H(r)$, so that the full message is $(H(r), m, H(H(r) || m))$. Revealing $r$ is then seen as the revocation of that data, since that is the only message required. ...


2

No, what you want to do is not possible, because encryption is randomized: if you were to encrypt the same message many times, you'd get many different ciphertexts. Therefore, Alice can't just compare two ciphertexts to see if they are the same; the two ciphertexts will be different even if they decrypt to the same thing.


2

One algorithm that is especially suited to one-use key pars is lamport signatures. Like many (all?) other signature functions, lamport signatures first hash the message to get it down to a size that is more reasonable to sign. For this use case, if you are willing to have $n^{2}$-bit signatures and $2n^{2}$-bit keys (public and private), you can sign a ...


-1

What do you mean by better security? RSA was proved to be as difficult as prime factorisation and is thus one of the best understood public key cryptosystems. Also, since its widely used their implementations have withstood years of attacks. Since you are going for a one-time usage of the keys, speed is not of importance (or is it?). If you can handle the ...


0

Since Alice encrypts the message $m$ she knows the plaintext. Now Bob computes F with the public key of Alice.Alice knows the secret key of the underlying homomorphic scheme and decrypts $C'$ and obtains the underlying values. This is how homomorphic schemes operate


5

The paper you link to in your comment is a fictional paper where the author (inspired by experiences with reviews he got for his own papers) imagines how negative reviews to groundbreaking papers could have looked like. So its just fun ;) AFAIK the RSA paper has never been rejected (but the very first paper of Ralph Merkle on public key crypto got rejected, ...


10

This depends on the public-key system (algorithm). For RSA, technically the private and public key (i.e. the exponents, the keys share the same modulus) are symmetric, you can swap them, and it still works. But you usually don't want to do this: The public exponent is usually a small number (like $3$ or $2^{16} + 1$) in order to speed up ...


3

This sounds like "fair exchange," the subject of many good research papers. In general you need a third party to give any security guarantees, but "optimistic fair exchange" involves the third party only when one of the parties tries to cheat (i.e., when both play honestly there is no involvement from the third party). Incidentally, Diffie-Hellman is most ...



Top 50 recent answers are included