30

I strongly disagree with saying that AES-128 is broken, in any way, shape or form, and likewise ECC with 256-bit keys. Note that even in this answer by @kelaka regarding AES-128, you would need over 34 million years of the entire bitcoin mining power to carry out a computation of $2^{128}$. This is far from broken. If quantum computers ever happen at scale, ...


15

As you specifically asked for comparisons of the 128-bit security with concrete things, here is some food for thoughts (to complement the other answers): $2^{61} ≈$ SHA-1 chosen-prefix collision (i.e. definitively practical) from the recent SHA-mbles attack. $2^{63} ≈$ the initial SHA-1 collision from SHAttered attack (which ran over multiple months). (i.e. ...


14

There are two main ways to have the same symmetric key on both parties: key exchange using asymmetric crypto generate the key from a known secret (eg: a password), such as using a password-based key-derivation function The former is what you will find in TLS, where public key infrastructure is used to verify the other party's public key. The latter is used ...


14

The library uses XChaCha20Poly1305 and that requires a nonce of 192-bit (24-byte). It is an extension of ChaCha20Poly1305 to increase the nonce size, ChaCha20 had 96-bit nonces. There is no standard for it, only a draft in ietf.org The nonce is an acronym for 'number used once'. The crucial point is that one must never use the (Key, nonce) pair again. We ...


11

Do you think that such algorithm can be commercialized[...]? This is very unlikely. AES is fast enough for most applications and where it isn't one usually uses (the cheap) hardware acceleration to fix that. Other common scenarios have the usually fast enough for them ChaCha stream cipher. This only leaves true edge cases on ultra-low power devices but this ...


10

I would say MiMC is the simplest block cipher with plausible security. The idea is to cube the state, add a random constant, and repeat. This is typically done in a large prime field, but it is trivial to implement field arithmetic in any language with big integer support. Here's a Python implementation: def mimc(x, p, k, constants): x = (x + k) % p ...


9

I will throw tiny encryption algorithm into the mix: https://en.m.wikipedia.org/wiki/Tiny_Encryption_Algorithm It's a very respectable block cipher. It really works as a block cipher with convenient block size of 64 bits and key size of 128 bits. So it behaves much like a DES or AES as in how you use it securely. It's a Feistel network which anyone starting ...


8

The current recommendations of the BSI recommend 120 bit of security beyond 2022. And AES 128 is still in their recommendations. If the current estimate of AES128 is about 126.1 bits of security, that's still above the threshold. And AES has been subject to a lot of cryptanalysis for many years, so that estimate seems quite strong. For crypto with keys, ...


8

The one time pad technically meets all your criteria and I think it's the simplest. It gets used all the time within encryption schemes where it's usually called blinding. Otherwise I would look into small block ciphers. For example, RC5 and skip32. These are probably the simplest beside the OTP.


7

The unique (we think) property of the cryptosystem offered by this mathematical discovery is that so long as Alice and Bob publicly choose a new particular mathematical object ($T$) to apply their key to before each message sent (of which there is a continuum of choices for $T$), they can use the same initially chosen key to send an arbitrary number of ...


7

The HMAC calculation is used as a KDF here. So 3 keys are derived. Let's start with the statement "In practice, if you know one, you'll know the other.". This is incorrect. The KDF construction uses a one way function so that you cannot get to the input keying material (or seed) s. This means that if an adversary gets hold of the symmetric key c that you ...


7

I think the most simple ciphers that are available are stream ciphers. Of course there are secure and non-secure stream ciphers. But e.g. LFSR's based ciphers are pretty easy to understand, and generally you just have to deal with bitops and basic possibly (modulo) addition. Those operations are generally easy to perform "by hand". Of course, to ...


6

The main reason to use a proper cryptographic authentication code is to ensure the very properties you listed. Your proposal of ciphertext and CRC (encrypted or not) fails to provide those. Let's consider three possible arrangements of data transmission with CRC: Plaintext message and CRC: CRC (Cyclic Redundancy Check) is meant to detect errors in ...


5

My sky-high level understanding of modern cryptography is as follows: there is an algorithm and a key. Sure, a key is generally generated for a specific cryptographic algorithm that takes a key. The key or key pair is a randomly generated number (I think). Not necessarily. AES and Serpent just take a key consisting of random bits. RSA uses two random ...


5

Does a cryptosystem exhibiting such properties already exist? For all practical purposes this looks like CPA-secure symmetric encryption which is a solved problem in practice and for practical purposes such a result would only be interesting if it managed to (on-average) encrypt one byte in less than 5 CPU-cycles on a modern CPU. Would a cryptosystem ...


5

AES is not an ideal cipher, nor is it intended to be an ideal cipher. AES is meant to be a practical cipher that offers a strength close to the key size. That means it is computationally infeasible to find the key even if given the plaintext and the ciphertext. AES - when correctly used with a strong mode of operation - produces ciphertext is ...


5

You shouldn't be concerned if you use PKCS#1 v2 encryption padding - the OAEP. OAEP, the Optimal Asymmetric Encryption Padding guarantees that even the slightest difference in raw plaintext (in your case, your symmetric keys) will result in huge difference in padded plaintext.


4

is there a property that guarantees that $D_{k'}(c)$ fails to verify/decrypt? No, there is not; all the security guarantees that authenticated encryption provides is of the form "if you don't know the keys, then it is difficult to..."; it says nothing about the difficulty of anything if you do know the keys. And, it turns out that, with GCM, you can ...


4

Why is the mechanism of encryption formulated in this way? Writing $D(d,E(e,\alpha)) = \alpha$ would imply that $E(e, \alpha)$ is a unique value, and it generally is not in practice (as most encryption schemes are, in fact, nondeterministic; that is, there are a number of ciphertexts that correspond to any specific plaintext). The text as written $\text{Pr}...


4

You shouldn't encrypt large files as if they were just one message; you should split them up into small chunks and encrypt each chunk separately with an AEAD, using some construction that: Protects against modification, reordering, insertion and deletion of chunks; Protects against truncation of the file; Rotates keys once too much data has been processed ...


4

There is no theoretically required here. ShiftRows changes the position of bytes, regardless of their value SubBytes changes the value of bytes, regardless of their position Therefore the order of these operations does not matter


4

A relevant example where you usually don't use the same key for encryption and decryption is actually AES (and any SPN-based cipher for that matter). The simplest point here would be that for AES you'd normally store your expanded key in order of usage in memory (to help with things like prefetching). However this would mean that the e.g. 11 round keys are ...


4

there may be a simple transformation to go between the (encryption and decryption) keys This answer gives an example with AES, a Substitution/Permutation Cipher (but note that AES has a few other differences between encryption and decryption). That also applies to Feistel ciphers in their common form where the final round does one less (or more) swap that ...


4

Yes. By any modern definition of a secure cipher, it can safely be used many times with the same key (the OTP can't safely reuse its pad/key, thus is not a proper cipher). Leaving a lot of formalism aside, RSAES-OAEP of PKCS#1v2.2 is a secure asymmetric cipher, which security is proven (to some degree, under some hypothesis including perfect implementation) ...


4

You are forgetting that messages usually consist of many blocks and that many messages contain much more structure than just English text. For example an RSA private key will, when encoded, have a easy to distinguish header and will consist of many blocks of plaintext / ciphertext when encrypted with a block cipher. The same is true for Word documents, XML ...


3

What is the real advantage of option 2 (asymmetric encryption of firmware)? As correctly pointed by the question, not much. All I can think of: It allows to change the symmetric key at each firmware release (actually, the firmware will be encrypted with a random symmetric key, sent asymmetrically encrypted in a header). This advantage is mitigated by the ...


3

The shared symmetric key is the same for all users? The shared key is exactly the same for each user, assuming they are connected to the same WEP access point. Because the nonce is concatenated with the key and fed directly into RC4, each wireless frame is technically using a different key (at least until the small 24-bit nonce repeats). This is unlike 802....


3

Hybrid encryption refers to an implementation of a public-key encryption interface by the composition of a public-key primitive to encapsulate a symmetric key that's used with a symmetric algorithm to encrypt the actual messages. The motivation is that public-key primitives don't perform nearly as well as symmetric ones, so this hybrid encryption optimizes ...


3

Trivium is designed as an 80-bit key and 80-bit $\operatorname{IV}$. Noted in Algorithms, key size and parameters report 2014. Technical report, ENISA - European Union Agency for Network and Information Security, 2014. increasing the key size was not an easy task. Kreyvium is defined in Stream ciphers: A Practical Solution for Efficient Homomorphic-...


3

Would it be a requirement that, given $f(k)$ and $c$, it is hard to rederive $m$? If so, then what you are effectively asking for is a public key encryption system; your public key is $f(k)$, and your private key is $k$. Such a method can be constructed from any public key encryption algorithm (but isn't any more efficient than the underlying pk algorithm). ...


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