We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

44

Before answering your questions: GCM is an authentication encryption mode of operation, it is composed by two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...


19

I will answer considering Linux OS, as being one of most popular Unix-like OS (between OSes which have urandom). If you need other OS, please, inform me. Also I will answer using source code of random.c driver from Linux 3.3.3 Kernel, because it is one of best documentation of /dev/random mechanics. And the other is paper: Analysis of the Linux Random Number ...


17

First, your use of 'echo' gets you: ~ % echo 'Attack at dawn!!' | hexdump -C 00000000 41 74 74 61 63 6b 20 61 74 20 64 61 77 6e 21 21 |Attack at dawn!!| 00000010 0a |.| 00000011 Note that there are 17 bytes there, not 16. echo adds a newline character. To stop that, use the -n flag: ~ % echo -n 'Attack ...


16

As for the leading zero, I believe the tools are just displaying what's in the ASN.1 as is; the BER/DER encoding rules will insist on a leading 00 byte in some cases. Specifically, if you encode a positive integer, the msbit of the value stored must be 0 (if it is a 1, the encoded value is assumed to be negative); if the msbyte of the value you want to ...


14

The question's bytestring 2a 86 48 86 f7 0d 01 01 01 is the Value field of an ASN.1 BER/DER TLV with type 6, which is the Object IDentifier for an RSA key (the Type and Length just before are coded as 06 09, and won't be further discussed). In order to parse that Value bytestring, we first separate the bytes into blocks ending after each byte which high-...


13

In a better world, TLS_FALLBACK_SCSV would not be necessary: SSL has been supporting downgrade-proof version negotiation since at least SSL 3.0, so a man in the middle should never be able to limit a connection to a version older than the mutually supported maximum. However, out there are some broken servers that don't really support that kind of version ...


12

AEAD modes like GCM are authenticated encryption with associated data; this setting only affects the associated data half of that. The ciphertext itself is still authenticated. The associated data portion is there to provide contextual information for the authentication of the ciphertext. Usually this data is something that's outside of direct control of the ...


11

DH: OpenSSL commandline has three options for creating certs, but all of them either selfsign the cert or require a selfsigned CSR, and DH can't do either of those. OpenSSL library called from a program you write can construct an X509 object (cert) containing a DH publickey, subject and other attributes as you specify, signed by an RSA key corresponding to a ...


11

The answer to "how much entropy" is always "128 bits". The tricky point is that the term "entropy" is very often misused. In general terms, the situation is the following: A computer is a deterministic machine. From knowledge of its complete state (contents of disk, RAM and CPU registers) at a time $T$, one can compute its behaviour and state at any time $...


10

The question is subjective in nature, and this comment is also subjective. It was too long to leave as an actual comment so I'm posting it as an answer, although it isn't really an answer, it's a comment. This is for posterity, I guess -- this thread is already high in Google searches. NaCl is probably the most widely respected library. It's authored by ...


9

You can make OpenSSL print out the handshake messages with the -msg parameter: openssl s_client -msg -connect myserver.net:443 Then look for the ServerKeyExchange message. Here is an example: <<< TLS 1.2 Handshake [length 014d], ServerKeyExchange 0c 00 01 49 03 00 17 41 04 6b d8 6e 14 1c 9b 12 4d 58 29 20 e8 e2 1a 24 0d da 8f 38 1a 5d 85 ...


9

If you reuse the same key material for different algorithms, you rely not on the security of any one algorithm individually, but on the security of the composition of the two algorithms simultaneously. For a particularly egregious example, if you use the same RSA public key for RSASSA-PKCS1-v1_5 and for HMAC-SHA256, the results might be entertaining. It ...


8

For what it's worth, in OpenSSL 1.0.2, s_client now displays the curve name: $ openssl s_client -connect crypto.stackexchange.com:443 [...] --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3436 bytes and written 443 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-...


8

As long as you use a secure padding mode (i.e. -pkcs or -oaep, not -raw). The default padding mode for openssl rsautl is -pkcs (i.e. PKCS#1 v1.5), so you should be OK. That said, OAEP is recommended over PKCS#1 v1.5 padding, so you might want to use the -oaep switch.


8

Yes, there are a number of TLS cipher suites that don't include any encryption. These cipher suites are not normally used by OpenSSL, but they can be explicitly requested e.g. using the -cipher option to the OpenSSL tools. Specifically, the suites offering no encryption and/or authetication are found under the NULL and aNULL cipher classes. The openssl ...


8

First off, using '-rand' is only seeding the OpenSSL RNG. It can be 1 byte or 1 TB. It's only used as a seed to get things started internally. Then, OpenSSL will use the systems entropy to actually generate the primes needed by RSA. Further, entropy is just a measure of unpredictability in a sequence, not an actual pool of stored bits. The larger the ...


8

The difference is inconsequential in this context. If you do some "processing" (e.g. generating a RSA key pair) using a deterministic and publicly known algorithm (e.g. OpenSSL's code) where the only parameter which is not known to the attacker is a random $n$-bit seed (e.g. $n$ = 256 for 32 bytes from /dev/urandom), then there is a theoretical possibility ...


8

Calculate $\phi(n) = (p-1) (q-1) = n - p - q + 1$. Then $d = e^{-1} \mod \phi(n)$. With OpenSSL, the code should look something like this (error checking omitted): BN_CTX *ctx = BN_ctx_new(); BIGNUM *d = BN_dup(n); BN_sub(d, d, p); BN_sub(d, d, q); BN_add_word(d, 1); BN_mod_inverse(d, e, d); BN_ctx_free(ctx); return d; If the public exponent is not known, ...


8

There are two facets in the use of TLS-1.0 with TLS_RSA_WITH_RC4_128_MD5. From a cryptographic point of view: TLS-1.0, as a protocol, is not broken. It does a number of things in a suboptimal way, forcing implementations to jump through intricate and topologically improbable hoops in order to avoid side-channel leakages. Recent implementations ought to be ...


8

The key is hexadecimal. So every two characters makes up one hexadecimal byte, which brings the length down to 32 actual bytes. There are 8 bits per bytes, so 8*32 = 256.


8

Yes, it is cryptographically secure, pseudo random output, seeded by retrieving secure random data from the operating system. If it is random or not depends on the fact if the OS RNG is random. This is usually the case on normal desktops, but you'd better be sure for e.g. limited embedded systems. If no truly random data can be retrieved - according to ...


7

Using the -k option, you can specify a password. Passwords are not really encryption keys, so OpenSSL uses a key derivation process to turn the password into an encryption key. It turns out by default OpenSSL uses a salt in that derivation process (which is why you see Salted__ in the output, which is a magic to indicate that the next 8 bytes are the ...


7

We need clear goals. The question asks for "plausible deniability" or "deniable encryption", and these terms needs a precise definition in a public-key context (implied by RSA). I assume that in addition to the IND-CPA and IND-CCA1 properties of a cipher, including hybrid (as implied by AES), it is desired that: One without the private key can't distinguish ...


7

There's no real difference between $p$ and $q$ in RSA. It looks like OpenSSL just has the agreement "$p$ has to be bigger than $q$" for conveniences. One of the numbers has to be bigger than the other (otherwise they would be the same number, and $p = q$ is very bad in RSA). Just use two examples: $p = 13$ and $q = 11$. $p$ is bigger than $q$, all right. ...


7

No, you can't; the reason you can't depends on the negotiated TLS ciphersuite: The original ciphersuites had the server send to the client the server's RSA public key; the client selects a random value ("premaster secret"), and encrypts that value with the server's public key; it sends that encrypted value to the server. Now, these public keys have the ...


7

It depends on what algorithm (determined by key type) and padding you use. If the key is a DSA key, or an ECC key used for ECDSA, those algorithms normally use randomized signatures to remain secure, and OpenSSL does so. (There is a variant scheme that makes k unique and unpredictable without making it truly random, but it is not widely used and not ...


7

To a cryptographer, "signing a document is to encrypt its hash using signer's private key" is wrong, because: It is specific to RSA and cousin cryptosystems including Rabin, and not even remotely descriptive of other common signature schemes; It misses an important step, padding, which is different for RSA signature and RSA encryption. If we use no padding, ...


7

Yes, you can do this. If you want to know how to do it (as opposed to just blindly copying a code snipped written by someone else and hoping it'll work), you'll need to understand a little bit about how CFB mode encryption works. First of all, CFB is a block cipher mode of operation. That is, it's a recipe for taking a block cipher like AES, which can ...


7

This code is very near the lines the error mentions for evp_enc.c (there may be some differences between different versions of OpenSSL): 527 n=ctx->final[b-1]; 528 if (n == 0 || n > (int)b) 529 { 530 EVPerr(EVP_F_EVP_DECRYPTFINAL_EX,EVP_R_BAD_DECRYPT); 531 ...


7

Yes, those encoded values are $r$ and $s$. The ASN.1 integers are signed big endian values while the two fixed sized values are unsigned big endian. So the value field may be identical or it may not, if: the value is equal to or larger than $2^{256 - 1}$: encoding this as signed big endian value will result in an additional byte at the left set to 00 to ...


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