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

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

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

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

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

4

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

The very fastest elliptic curve algorithms can generate a key-pair in about 40k cycles on a modern CPU. A high end laptop has four cores running at about 3 GHz, so it can generate about 300k key-pairs per second, or a billion per hour. (The cost of SHA-256 is negligible in comparison.) However, secp256k1 is nowhere near the fastest curve. It takes 10 times ...

2

When doing backups to an online (cloud) provider, I split first, then encrypt. My files are all first tarred together, and the resulting file can end up being many GB in size. If I try to encrypt that large tar file, it would take hours or days, and any problem will cause the encryption process to fail with no option to resume. By splitting first, I can ...

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

SSL/TLS is a secure protocol that encorporates the negotiation of cryptographic parameters for asymmetric and symmetric algorithms, integrity algorithms, and verification algorithms. You can read more about this on How does TLS work? You can find more information on the cipher suites used for negotiations in this answer. The same API used for SSL/TLS is ...

2

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

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

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

Well, they say they use gpg to sign the file (yubico-utf-ca-certs.txt) and the signature is in the linked file. So gpg --verify yubico-u2f-ca-certs.txt.sig yubico-u2f-ca-certs.txt gpg: Signature made Tue Sep 2 11:18:24 2014 CEST using RSA key ID 32F8119D gpg: requesting key 32F8119D from hkp server keys.gnupg.net gpg: key 54265E8C: public key "Simon ...

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

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

The HSM is not supposed to expose its actual key material; that's the whole point of them, often: they're not as easy to compromise as a PC where key material is in memory that can leak etc. The value 86016e6572617465642044455333204b6579000000000000 is just, after the first two bytes, the ASCII representation of "enerated DES3 Key", which makes it very ...

2

AES operates on 128 bits of data. We can use modes of operation to turn AES (and any block cipher for that matter) into something that can handle longer (or shorter) data. If you want the ciphertext to be limited to X bits (above you said characters, I'm switching this to bits to make things easy), X must be at least as long as the plaintext data ...

2

Meta: since this is about using a tool not the underlying algorithm/math AIUI should be security.SE instead. If anyone can and wants to migrate feel free. Per 1.0.2 source, -sigopt rsa_mgf1_md:name where name is the name of a hash available to EVP_getdigestbyname -- that is, implemented and not #if'ed out by default (MD2) nor manually. For FIPS mode if ...

2

Asn1parse to the rescue. Most of the overhead is from the base64 encoding and the PEM header and footer. The raw size of the compressed form ASN1 encoding is just 44 bytes for my dummy key. And 22 of those bytes are for the 161 bits of the actual public key. \$ openssl asn1parse -in compressed_public.pem -i -dump 0:d=0 hl=2 l= 42 cons: SEQUENCE ...

2

I'm not sure, but I guess that two different openssl version or just builds could be done with or without support of Elliptic Curves with unsecure security levels. Furthermore your curves have very low security level, and you shouldn't use them if security is a concern (and if it's not, you probably don't need ECDSA at all). However, your assumption that ...

2

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

2

Or does OpenSSL derive the IV by the decryption key somehow from the packet ? Well, yes. Actually, it's not that complicated; for DTLS and AES-CBC mode, the IV is the first 16 bytes of the encrypted region, so it just reads it from there, and starts decrypting from there. In DTLS, we assume that encrypted packets can be dropped in flight (or received ...

1

openssl genrsa -out yourRSAkeyfile.pem

1

Let me try to provide an answer for your question (despite the answers in the comment section). Some research showed that a recently discovered vulnerability allowed to extract the keys from SafeNet HSM (which the Luna G5 is). Therefore it should under normal circumstances NOT be possible to extract any private keys from the HSM. To your question in the ...

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

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