# Tag Info

6

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

4

Both curves have similar form and primes close to powers of two ($2^{192}-2^{64}-1$ and $2^{224} - 2^{96} + 1$), so you wouldn't expect large differences in performance – all things equal, P-224 might be anywhere from 30% to 60% slower due to the computational scaling of curve operations. However, in practice different implementations will have different ...

4

I ran the command under dtruss on OSX, with it pointing to a static file. Even then, it appears to use this as an additional source of randomness to /dev/urandom. It's distasteful and almost certainly pointless. But assuming it only mixes the data into an already cryptographically-secure source of randomness, it's not actively harmful. That said, I can only ...

3

The certificate is not encrypted. It contains signatures (basically hashes) that are encrypted with the private key. The public key can decrypt that and the hash can be verified. In SSL/TLS there is a signature that the client supplies via private key to prove they are the owner, and the CA has signed it the cert with their private key, which can be ...

3

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

3

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, n); BN_ctx_free(ctx); return d; The inverse calculation is less ...

3

Just compute the multiplicative inverse $k^{-1}$ of $k$ modulo the prime order $n$ of the base point $G$ (I used the typical notation for the domain parameters of the curve). This can efficiently be done using extended Euclid and should be available in any reasonable big integer library (typically something like modinverse). Thats it.

3

It looks like there's an error in the test vector. The text of Appendix B.1 states: P1 = “The quic” = 5468652071756663 ... which is incorrect. The hex encoding of The quic is actually 5468652071756963 (note the transposition of the i/69 to an f/66 in the encoding. e.g. encrypting the test vector as intended: $echo -n 'The quick brown fox jump' | ... 2 Why not using VeraCrypt http://en.wikipedia.org/wiki/VeraCrypt, which is a successor of the famous discontinuited TrueCrypt. VeraCrypt is open source, and was developped by M. Idrassi an crypto-expert, take a look at https://github.com/veracrypt/VeraCrypt . There was controversy about the TrueCrypt, mysterious stoping. VeraCrypt corrected some know flaws and ... 2 The -bf-ecb cipher is expanding the key to 128 bits by zero extending it. The output from -p is the telltale here:$ openssl enc -bf-ecb -e -in plaintext.txt -out ciphertext.txt -nosalt -K FFFFFFFFFFFFFFFF -p key=FFFFFFFFFFFFFFFF0000000000000000 Blowfish is defined for 32-448 bit keys, and it appears the OpenSSL implementation chose 128 bits as the size ...

2

Most binary network protocols are already bounded. So if you just send the ciphertext (or the IV and the ciphertext) then the length will be known by the transport mechanism. Otherwise the method of communicating the length is entirely up to your imagination as long as you can map it to a presentation that is acceptable to your transport protocol. Null ...

2

Commandline openssl enc normally does Password Based Encryption which derives the actual key, and IV (although IV is ignored for ECB), from the password or passphrase you enter, using a variant of PBKDF1. To get "raw" encryption you must specify the key in hex with -K (uppercase), in which case -nosalt is irrelevant (because it applies only to PBKDF). Except ...

2

[...] the only one that is listed (secp256k1) are marked as unsafe. Some of the others are there too. NIST P-224 is the same curve as secp224r1, and similarly for P-256 and P-384. Those are marked unsafe as well. Assuming we trust djb, are the elliptic curves that are currently supported by this reasonably new version of OpenSSL (and therefore ...

2

ECB is not secure even with per file keys, because if two blocks of the file are identical, this is visible in the ciphertext. The only * cases where ECB is secure is encrypting completely random data or encrypting a single block per key. You should pick something more secure if your can help it. If there is literally no other option than RC4 and AES ECB, ...

2

You can use your HardwareID as basis for the encryption key. If the ID provides enough entropy it'll work. However, if anyone can somehow obtain the ID (which might be quite easy to do) one can decrypt the file. For CFB-Mode the IV must indeed be unpredictable (but need not be secret), so random is just fine, but DO NOT REUSE AN IV. Encryption large ...

2

openssl rsa -pubin -inform PEM -text -noout < public_key.pem Public-Key: (64 bit) Modulus: 16513720463601767803 (0xe52c8544a915157b) Exponent: 65537 (0x10001) The modulus is small enough that you can easily factor it After finding the prime factors, you can calculate the private exponent After you have the private exponent, you raise each 64-bit block ...

2

Based on your description, you will not be able to recover the original encrypted file. Since you specify that you used a password and do not indicate the use of an IV, my assumption is that you did, in fact, use a passphrase rather than a secret key. When you encrypt a file with a passphrase, OpenSSL assumes that it is a low-entropy string unsuitable for ...

1

The generated private key is same for both client and server is it true? No, that's not true. The key pairs and thus the private keys will be different. They will only be the same if the random number generator creates 521 identical bits for both the server and the client when the key pairs are generated. Client send its public key first or Server? ...

1

First, RSA "encrypt with private key" and "decrypt with public key" are semantically wrong; these don't provide confidentiality which is the purpose of encryption, but they can provide integrity which is the purpose of signature. The fact that RSA sign/verify operations are mathematically similar to encrypt/decrypt led to this misuse of terminology back in ...

1

The inventors of the Supersingular Isogeny Key Exchange, Defeo, Jao and Plut have posted some code on GITHUB at: https://github.com/defeo/ss-isogeny-software/ There is also a paper on implementation of this key exchange by some people from the University of Waterloo. Their paper is "Efficient Implementations of A Quantum-Resistant Key-Exchange Protocol on ...

1

You can start by reading: https://github.com/openssl/openssl/blob/master/engines/ccgost/README.gost It has examples on how to generate GOST certificates. After that I would suggest running a test SSL/TLS connection with those certificates and openssl s_client and openssl s_server utilities. If it works, you may then recompile OpenSSL and make it dump all ...

1

I'd suggest to get OpenSSL source, build it, and run it under debugger, watching exactly what "-text" is doing to private key. One could verify exponentiation operations with a calculator having big numbers capability. ASN.1/DER parser could be handy to see private key file.

1

Cipher Feedback mode turns the block cipher (AES) into a self-synchronizing stream cipher which feeds back the full ciphertext block as the next IV. If you encrypt something smaller than a multiple of the block size, it will not use all of the block cipher output to create the ciphertext, just the amount it needs. Therefore there is not a padding ...

1

With OpenSSL the forward cipher for EVP_aes_265_xts is AES 256. The key being 512 bits, internally split into two 256 bit keys for each of the AES 256 ciphers used within the XTS mode of operation.

1

Not a definite answer but too much for comments: That help msg shows that OpenSSL on OSX is an old version (<= 0.9.8) before GCM was added. (Probably =; 0.9.7 end-of-lifed around 2008. -salt has been the default since about 2004 so anyone who claims you need to specify it should be treated very skeptically.) You could add HMAC on top of AES-CBC ...

1

The "normal", unmodified RSA (called textbook RSA) is susceptible to some attacks. We need to change it slightly to avoid this problems. The question Definition of Textbook RSA and the Wikipedia lists some possible attacks. In practice a special padding algorithm is used, like the Optimal asymmetric encryption padding (OAEP). The documentation of the ...

1

the following command do what I want : openssl smime -in msg -pk7out -out msg.pk7 openssl asn1parse -in msg.pk7

1

I think that you're asking how to generate a timestamp response as defined in timestamp-protocol: RFC3161, with openssl to generate and sign the response using a PKCS#11 (HSM in your case) as a TSA signer. I think that there is no native way to use PKCS#11with openssl to do this. (maybe with some plugin like: opensc pkcs11 engine for openssl). If you take ...

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