# Tag Info

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

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

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

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

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

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

ECKEY object may contain: Group Private key Public key Both Group and Private key are needed to be able to calculate signature. It is most convenient to use generic ECKEY object (from API perspective), as it easy to e.g. convert between commonly used PKCS#8 PEM encoded EC private keys and ECKEY objects, and because just a BIGNUM would not be sufficient. ...

2

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

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

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

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

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

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

1

The general idea to derive keys from (ephemeral) Diffie-Hellman key agreement is to use a KBKDF - a key based key derivation function. KBKDFs are mostly ill defined with regards to what security requirements they adhere to. Fortunately creating a KBKDF isn't thought to be too hard. Using a cryptographically secure hash generally gets you a long way. You ...

1

What format must the x-coordinate bignum be converted to before hashing it? Any format works as long as it uniquely encodes the shared secret and is used by all parties. So if your code doesn't need to interact with other implementations, you can use whichever you like. If you need interoperability, you need to look at what others are using. E.g. SP ...

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

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

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

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 following command do what I want : openssl smime -in msg -pk7out -out msg.pk7 openssl asn1parse -in msg.pk7

1

This may be off-topic since it is really about OpenSSL... For your question 1, the values you get are the prefix 04 (which indicates that the point is represented in uncompressed form) followed by the $x$- and $y$-coordinates of the generator. Here you have 97 bytes, so eliminate the first byte and then you have both coordinates, which take 48 bytes each. ...

1

(moved from comment, expanded slightly) (AES) Key Wrap is not the same as normal data encryption like CBC or GCM; it does quite a bit of remixing, and adds exactly 64 bits to any AES "plain key" (here 256 + 64 = 320 = 40 bytes) even though it uses the AES algorithm which has a 128-bit data block. See http://tools.ietf.org/html/rfc3394 and the relevant ...

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