Tag Info

Hot answers tagged openssl

17

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

12

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

10

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

10

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

9

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

8

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

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 ... 8 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 ... 8 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 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 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. 7 Either could be implemented securely, but if you encrypt first and split afterwards, you can use standard tools and get everything right more easily. If you used the opposite order, you would have several pitfalls to deal with: With password-based encryption you would either have to derive the key many times (spending resources that would be better used on ... 7 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 ... 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. ... 6 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 ... 6 In the example you linked, the current time (specifically, a value representing the number of seconds elapsed since Jan 1, 1970 UTC) is used as the seed. If an attacker knows which year you generated your key, then that leaves only about 2^25 possible values for the seed --- and therefore only about 2^25 possible values for your key. At this point, he can ... 6 An initialization vector is, in fact, always binary. It's just random bits. So, if you choose to encode those bits as a hexadecimal string for ease of storage or transportation, that is fine. However, since it is the binary that is the IV, you will need to decode it back from hexadecimal to a binary value before using it in the decryption process. As a ... 5 You can decrypt with the -nopad option and check the HEX output. Example piped command :$ echo "hi" | openssl enc -aes-128-cbc -e -K 1001001 -iv 0100110 | openssl enc -aes-128-cbc -d -nopad -K 1001001 -iv 0100110 | hd And output : 00000000 68 69 0a 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d |hi..............| 00000010

5

The public exponent of a RSA key is, nominally, an odd integer $e \geq 3$. Any such integer can be used with RSA, although not necessarily with any modulus $n$: $n$ and $e$ must be such that $e$ and $\phi(n)$ are relatively prime to each other. This is why $e$ cannot be even: $\phi(n)$ is even, so it can never be prime to another even number. Apart from ...

5

There's nothing inherent in the RSA decryption operation that requires the public exponent; it's just: $P = C^d \mod N$ (or a slightly more complex version involving the CRT parameters) So, strictly speaking, OpenSSL doesn't have to insist on it. On the other hand, there are some protections against side channel attacks that involve the public ...

5

Be aware that your solution will touch much more than cryptography. Your command shell, the account it runs on, the swap file, the whole machine falls under the purview of PCI DSS regulation and auditing. If you can avoid storing or even handling the number, so much the better.

5

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

4

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

4

I recommend against using RAND_pseudo_bytes(). OpenSSL's CPRNG does not provide better pseudo-random numbers than /dev/urandom but it is much harder to use right. It has a couple of known flaws, for example it doesn't handle fork() very well. The standard PRNG is not very well designed, too. The FIPS mode PRNG is a bit better, though. /dev/urandom (Linux, ...

4

I see a few issues with this approach: First, since you're signing the ciphertext and sending the signature in plain, anyone who has your public key can verify that you did, in fact, sign that message, even if they won't be able to actually decrypt it. This may or may not be something you want. More importantly, anyone who intercepts the message can strip ...

4

AES is a block cipher, a cryptographic primitive. It has no involvement with key derivation or anything of that nature. The three standard key sizes are 128 bit, 192 bit, and 256 bit. How you get those keys is beyond the purview of AES, which is concerned only with encryption. As I said, it is a cryptographic primitive, meaning it is meant to be used in a ...

4

The documentation says: All the block ciphers normally use PKCS#5 padding also known as standard block padding which is both informative, and slightly misleading. OpenSSL supports, by default, one stream cipher (RC4) and a variety of block ciphers (Blowfish, 3DES, AES...). The enc command (from the command-line tool) encrypts an input file into an ...

4

The smallest safe prime you got from OpenSSL was 3221226167 = 0xC00002B7. The largest was 4294967087 = 0xFFFFFF2F. This makes me hypothesize that OpenSSL is setting the two high bits to one, and choosing the rest of the bits randomly. If that is accurate, that would explain the range of primes you did. As far as why you found many more safe primes in the ...

4

In 0.9.8 there is only PKCS5_PBKDF2_HMAC_SHA1. Sample C code: #include <openssl/evp.h> #include <openssl/sha.h> void PBKDF2_HMAC_SHA_1nat(const char* pass, const unsigned char* salt, int32_t iterations, uint32_t outputBytes, char* hexResult) { unsigned int i; unsigned char digest[outputBytes]; PKCS5_PBKDF2_HMAC_SHA1(pass, ...

4

No it is not less secure. GCM and a number of other authenticated modes typically let you specify optional data which is authenticated but not encrypted. That is all this is. So the code is making it explicit that there is no data that is only authenticated.

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