# Tag Info

22

Why shouldn't I use ECB encryption? The main reason not to use ECB mode encryption is that it's not semantically secure — that is, merely observing ECB-encrypted ciphertext can leak information about the plaintext (even beyond its length, which all encryption schemes accepting arbitrarily long plaintexts will leak to some extent). Specifically, the ...

17

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...

14

I try to provide a brief intro. ABE Attribute-based encryption (ABE) is a relatively recent approach that reconsiders the concept of public-key cryptography. In traditional public-key cryptography, a message is encrypted for a specific receiver using the receiver’s public-key. Identity-based cryptography and in particular identity-based encryption (IBE) ...

14

You should not use ECB mode because it will encrypt identical message blocks (i.e., the amount of data encrypted in each invocation of the block-cipher) to identical ciphertext blocks. This is a problem because it will reveal if the same messages blocks are encrypted multiple times. Wikipedia has a very nice illustration of this problem.

12

Synchronous stream cipher, or just stream cipher. In a synchronous stream cipher a stream of pseudo-random digits is generated independently of the plaintext and ciphertext messages, and then combined with the plaintext (to encrypt) or the ciphertext (to decrypt). In the most common form, binary digits are used (bits), and the keystream is combined with ...

11

Yes, it's the same XOR. It gets used inside most of the algorithms, or just to merge a stream cipher and the plaintext. Everything is just bits, even text. The word "hello" is in ASCII "01101000 01100101 01101100 01101100 01101111". Just normal bits, grouped in 5 bytes. Now you can encrypt this string with a random string of 5 bytes, like an One-time pad. ...

11

n is the exponent. So when n is doubled from 64 to 128 it doesn't mean that you have to try twice as many values. It means that you have to try $2^{64}$ times the amount you were already trying (as $2^{128} = 2^{2\times64} = 2 ^{64+64} = 2^{64}\times2^{64}$). It is required to only search half of the key space on average (if average is the correct term ...

10

This depends on the public-key system (algorithm). For RSA, technically the private and public key (i.e. the exponents, the keys share the same modulus) are symmetric, you can swap them, and it still works. But you usually don't want to do this: The public exponent is usually a small number (like $3$ or $2^{16} + 1$) in order to speed up ...

10

Yes, of course there is a benefit to signing unencrypted emails. The article you cite is solely about the combination of signature and encryption; it doesn't directly say anything about signing unencrypted emails. There is an important concern raised by the article which does apply to unencrypted emails, but that's because that concern applies equally ...

9

In terms of marketing hype, that statement rates about a 9 in a scale from 0-10. The reason is that we don't choose the encryption algorithm based on how many bits the CPU can handle at once. Instead, we choose a secure algorithm, and then implement it using the resources that the CPU provides us. There aren't any algorithms we cannot implement on a 32 ...

9

Perceptual encryption is a term used to describe various applications of encryption methods intended for audio, speech, image and video data. The basic idea is that one performs encryption for multimedia content in a way that only a certain amount of "perceptual information" is touched by the encryption. It may be considered as intentionally degrading the ...

8

The article you linked to predates the S/MIME 3.2 spec. If your client is sending S/MIME 3.2 messages, it should support header protection. Refer to RFC 5751 Section 3.1: In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message ...

8

Python is a scripting language, so if you've got the program, you usually also have the source code. So you don't even have to reverse-engineer. That doesn't matter much for two reasons: other languages are pretty easy to reverse engineer (or they are complex for both the programmer and the attacker); the algorithm does not have to be kept safe anyway, due ...

8

There are many different cryptography laws in different nations. Some countries prohibit export of cryptography software and/or encryption algorithms or cryptoanalysis methods. In some countries a license is required to use encryption software, and a few countries ban citizens from encrypting their internet communication. Some countries require decryption ...

8

A Diffie-Hellman exchange needs not be synchronous. In DH, each party has a private key (x) and a public key (gx mod p). If the sender knows the recipient's public key ga, then he can build his own key pair (b and gb), compute the shared secret (gab), and send both his public key (gb) and the encrypted message (symmetric key derived from gab) to the ...

7

Short answer No, RSA encryption with a private key is not the same as RSA signature generation. RSA encryption can only be performed with an RSA public key according to the RSA standard. The terms Raw RSA or textbook RSA are often used to indicate RSA without a padding scheme. Raw RSA simply consists of modular exponentiation. Raw RSA is vulnerable to many ...

7

You could use HMAC for this. HMAC is available in pretty much every crypto library out there. The process would work like this. Randomly pick A and C. For simplicity, let's assume they are strings (of any length). Compute $B=HMAC(A,C)$. Publish $B$. Once someone guesses $A$, you publish $C$. Anyone can then verify that $B=HMAC(A,C)$. As long as a good hash ...

7

The point of cryptography is having algorithms that are secure even when the attacker knows them. Google security by obscurity to see why it's bad. I'll add the following based on otus comment. Python can be reverse engineered, so you can't hide your algorithms. Basically, if someone can run your code, they can reverse engineer the algorithms. The point of ...

7

You can in principle encrypt using a hash function, in the manner you describe (although what you have described is not necessarily a secure construction). What you are trying to do is generate a keystream from a hash function and a key. You can use counter mode to turn any strong pseudorandom function (PRF) into a stream cipher. CTR mode produces a ...

7

This is called a transposition cipher. It is the kind of thing that was commonplace before the invention of the computer, and some people were really good at breaking that in mere minutes (e.g. Edgar Allan Poe). In all generality, breakage is done by backtracking (wrong hypotheses on permutation elements leading to "impossible digraphs" that cannot occur in ...

6

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not ...

6

OpenPGP as defined by RFC 4880 knows two different encodings. Binary encoding Obviously, there is no reasonable limitation to an (ASCII) character subset in binary encoding. Radix 64 Radix 64 is also often entitled ASCII armored. In the end, it is a base64 encoding with a checksum. The content may consist of [a-zA-Y0-0+/=]. ASCII-armored OpenPGP ...

6

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...

6

There are three distinct computational problems related to RSA. They are: FACTORIZATION: given an RSA modulus $n$, find its prime factors $p$ and $q$; ORDER: given an RSA modulus $n$, find the order $\lambda$ of the multiplicative group modulo $n$; RSA Problem: given a ring element $a \in \mathbb{Z}_n$, a public exponent $e$ and an RSA modulus, find an ...

6

What you describe is known as Threshold-secret-sharing, for which a good candidate is the threshold version of shamir-secret-sharing. In particular, for your use case I would recommend implementing an "n-1 out of n threshold sharing scheme". Shamir Secret Sharing $(n,k)$-threshold scheme. Shamir's $k$ of $n$ threshold sharing scheme is based on the ...

6

To make it easier for humans to read.

6

Before answering your questions: GCM is an authentication encryption mode of operation, it is composed by two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...

6

Yes, the XOR used in cryptography means the same bitwise XOR operator you're familiar with. And yes, to securely encrypt a message with XOR (alone), you do need a key that is as long as the message. In fact, if you have such a key (and it's completely random, and you never reuse it), then the resulting encryption scheme (known as the one-time pad) is ...

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