New answers tagged

2

Yes, it is safe. The answer of @kelalaka (the first part, before update) it not correct. The OP is saying that the password is a strong string which is hard to bruteforce. That's why the answer of @kelalaka the attacker, firstly, will try to brute-force is not relevant to the question. Everything @kelalaka is saying about password stretching is correct, but ...


-2

As kelalaka suggested, a single SHA256 hash of the password is not sufficiently secure, although it works. PBKDF2 uses many chained iterations of a hash like SHA256 to derive an AES key from a password. bcrypt, scrypt, and argon2 are newer key derivation functions that increase the difficulty of deriving the key by implementing an iterative hash that also ...


0

For huge amounts of data it would be better to re-key periodically. You could do something like hash your initial secret with SHA256 every 1GiB of data and re-key AES with new secrets. If I were designing this from scratch I'd put a large (e.g. 512-bit) random nonce at the start of the large message/stream. Then I'd use part of this nonce to seed a CSPRNG ...


2

We assume that the attacker knows the key generation method, too. Therefore, firstly, the attacker will try to brute-force for possible strings and simple combinations. Users should choose a good entropy source for this kind of method. If the user has hard-to-bruteforce string to enter any Cryptographically secure hash function, i.e. it has pre-image, ...


7

CTR is insecure if you reuse a key/iv pair. Since the salt is random, a different encryption key will be derived every time you encrypt something. Therefore it is safe even if it always uses the zero IV. Of course, the password must be strong enough to resist brute force attacks.


1

There is no way to detect the wrong key before decrypting: I can create a message M, a totally valid and legitimate key K, and then I encrypt the message with a different key K': Any information that I give you about the key K will be totally legitimate and fine, it will just not be about the key I used to encrypt the message. You can try to include ...


3

Exposing the size of the plaintext has no security risks. The size of the plaintext is always considered public data. It's not done because it has limited benefit. With a mode like CBC, you cannot encrypt a fractional block. You must pass a whole number of blocks to the encryption function. So you need padding in some form. The ciphertext is a whole number ...


1

the raw result is truncated to this saved length. You can easily truncate only if you work with small data sets or if you need to encrypt/decrypt a single file / data set. If you have relatively big data set, let say 1 GB, you would first have to save them in a temporary file. If your OS does not support truncating files, you will have to reread this file ...


3

Ilmari Karonen already mentioned using an authenticated encryption mode, which would solve the concerns, but should you not go that way, please note the flaw in your premise: If one provides the wrong key to the decryption+decompression function, the decompression stage will explicitly fail, as expected, since the decrypted content (being based on the ...


1

There are a bunch of issues with prepending the message's length to a ciphertext (or indeed encoding it as the first few bytes of plaintext): Lack of Benefit: Explicitly encoding the length when using CBC mode gives you a benefit in exactly one case: When the entire last block would be padding, because otherwise you will need the length and the padding. ...


33

You should use an authenticated encryption mode. There are several reasons for that, but one (relatively minor) one is that it automatically gives you the ability to detect incorrect keys, since the authentication will fail. If you insist on using a traditional non-authenticated encryption mode, or if you'd like to have some way of distinguishing "...


2

Would there be any benefit to symmetrically encrypting the IV and MAC in an AEAD mode of operation? Not really. The MAC is already encrypted as part of GCM mode. Encrypting the IV just hides it, decryption of the message still requires the key. More specifically would this prevent someone from exploiting the accidental use of a duplicate IV with the same ...


5

If a (nonce, key) is reused with two distinct messages A and B, an attacker can learn A⊕B = E(A)⊕E(B). So, if either plaintext is known, the other one can be immediately decrypted. This is why nonce-misuse resistant schemes require two passes: a first pass to compute a hash of the message, the second one to perform the actual encryption with an IV, and ...


3

There are no unbroken and published designs. The strongest recently published design from CHES 2017 challenge withstood attack for slightly less than a month. If you can, choose an alternative to AES white-box: use hardware-backed operating system features to store and use the key (e.g. Android Keystore, iOS Secure Enclave) use trusted application in TEE (...


2

It's obviously not the AES SBox. In that SBox, input 0E maps to the value AB. Your table has the horizontal row 7, and the vertical row 15 to give output AB - there is no obvious way to translate input 0E as "horizontal row 7, vertical row 15" However, you asked if it were an AES SBox - that's rather like asking if a tower was "an Eiffel Tower"


0

AES-GCM can be used as a as stream cypher by splitting the input to multiple blocks along with a nonce. However using AE for each block may not be an efficient technique. See this topic Also read this post.


1

The problem with CBC mode is the padding. When there is a padding error, the server must response a message back to you so that you can send the message back again or encryption the message from the beginning. The padding oracle attack is solely based on this idea. The attacker changes the byte and looks at the response of the server to execute the attack. ...


3

Your understanding is correct. PKI would be the service that verifies that Bob's public key really belongs to someone named "Bob". As long as Alice trusts the certificate authority that certified Bob's public key, she can implicitly trust that the public key she sees really is Bob's, not Eve performing a MITM. The internet is secured with web PKI, which is ...


3

This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation. ...


0

For the parameters you gave, the birthday paradox will kick in and you will get collisions, since the set of integers you want to process is much larger than $\sqrt{2^{30}}$. A very simple countermeasure would be for input $x_k$ to use bits $(y_{k,1}\ldots,y_{k,30})$ of the AES output $$ (y_{k,1}\ldots,y_{k,128}):=AES_K(x_k) $$ (for a fixed randomly chosen ...


3

You can encrypt with secp256k1 (or any elliptic curve) by using ECIES (Elliptc Curve Integrated Encryption Scheme). However, inside ECIES a symmetric key is generated and the message is encrypted using it. This is in contrast with RSA, which can encrypt data directly; though most of the time it is also used to encrypt a symmetric key and then encrypt data ...


2

AES doesn't require uniformly distributed keys. However, if you have a key with less than 256 bits of entropy, then naturally your keyspace will be smaller than the maximum. Whether or not this is an issue depends on just how few bits you have. The only time a non-random key is bad for AES is when it's chosen very specifically to be harmful, in which case it ...


2

I mailed Craig Federighi recently about this, concerned that macOS wasn’t capable of generating >128bit quality keys. He responded! “The source you were referencing is out of date. You can find more current informations here: FIPS certification document, section 7: "The NDRNG feeds entropy from the pool into the DRBG on demand. The NDRNG provides ...


0

Does it add "more security" [...] flipping a bit (or two) of each AES block and store information about the flips alongside with the key and IV in the RSA encrypted part (so that the recipient can decrypt properly)? This would essentially be a stream cipher applied to the ciphertext, as a stream cipher encrypts by unpredictably deciding for each bit whether ...


7

TL,DR: No, don't do it. Use a standard protocol and don't write your own implementation. If you're thinking at the level of AES, CBC and RSA, you're doing it wrong. I recommend crypto_box. I am developing a software with hybrid encryption (RSA-4096 RSA-4096 is ok if done right. Done right means OAEP or RSA-KEM. PKCS#1v1.5 is theoretically possible to ...


0

The title says authentication, that is we want only the real firmware to load and run, unmodified. There are fast, practical code signature techniques for that. Most importantly they require no secret in the target device. The baseline would be that the target contains an RSA 2048-bit public key with $e=3$, and uses that to verify an RSASSA-PKCS1-v1_5 ...


1

For reference, this is the Ansible Vault format. In short: It derives an AES key, HMAC key and IV from the password using a 32-byte random salt It encrypts the data using AES-CTR with the derived key and IV It MACs the ciphertext (but not the IV) with HMAC-SHA256. Not including the IV is usually bad, but since the IV is derived from the password and salt ...


5

Currently we do not think that 512 bit DH is secure. You can look for more secure parameters (i.e. above 1280 bits at the very least) is secure. Secure key sizes can be found at keylength.com. For DH you can e.g. look at the NIST recommendations for "Discrete Logarithm" (the underlying mathematical problem that is the base of DH-based cryptography). Using ...


1

The limit is on a per-key:nonce basis. As long as the key or nonce are changed between messages before the limit, there will not be any problems. Different users are using different TLS sessions (which uses 96-bit nonces), which means different keys and nonces. From Wikipedia's page on GCM: GCM has been proven secure in the concrete security model. It is ...


1

No, it uses a specific type of algorithm called a key schedule. Unlike a KDF, it is not designed to be slow (in the case of a password-based KDF) or to be irreversible. The requirements of a key schedule are quite simple. Whereas a KDF might need to expand a key into a number of keys such that knowledge of any one key does not reveal knowledge of the master ...


1

The first question you should ask yourself is what you are trying to protect against. AES-256 is even considered secure against quantum computers. Certainly a brute force attack is already far out of reach. So if AES breaks it is likely because the algorithm is broken. In that case neither of your schemes may save you; you would have been better off using an ...


3

Cryptographic security is not a one-dimensional spectrum. Increasing the key size increases keyspace, which is the maximum number of possible keys that must be iterated through to complete a brute force attack. Increasing rounds, on the other hand, reduces the chances that novel cryptanalysis, which allows an attacker to break the cipher faster than brute ...


Top 50 recent answers are included