# Tag Info

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

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

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

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

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

5

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

4

Based on the additional details in the comments, it seems like your question is: given $c_1=a\oplus d$ and $c_2=b\oplus d$, can we get $(a+b)\oplus d$. Where $a,b,d\in\mathbb{Z}_p$, $+$ is addition modulo $p$, and $\oplus$ is a bitwise XOR of the values, then taken modulo $p$. Or put another way, is there an operation $\boxplus$, such that $(a\oplus ... 4 The benefit to signing a non-encrypted email is that any recipient can verify that it was indeed you who wrote that non-encrypted email, unless your key was compromised (or the signing protocol has an exploit). 4 Your teacher is right, and here's why: What happens if you encrypt A with G and B with G? You can't decipher it, because you have no idea if the G in the ciphertext was an A or a B. So for the plaintext letter A you can use the ciphertext letter A, B, C, D, ..., Y or Z. (26 possible letters.) For B you can use A, B, C, D, ..., Y or Z, but not the letter ... 3 I starts with all relevant references I found, then tentatively answers the question. Feel free to improve this community wiki. It was originally asked the effort to break PKZIP 2 encryption, described in section 6.1 of the .ZIP File Format Specification (with some refinements in the derived Info-ZIP appnote), assuming a high-entropy password (that is, ... 3 The problem can be simplified to the following problem, since the standard argument doesn't really take into account that you can't generate all the polynomials of the given maximum degree : Assume that we have sampled a random point$\vec{x}\in \mathbb{F}_p^n$. We let an adversary adaptively choose polynomials of degree at most$d$and after each choice ... 3 If you aren't worried about collusion or dynamic group membership, then a very simple solution is to simply have one key for encrypting the messages and another for signing them. The encryption key gives someone read access and the signing key gives them write access. Only nodes with the encryption key will be able to successfully decrypt the messages and ... 2 For security in Shamir secret sharing we need that the coefficients of the polynomial are independent and uniformly random in the field. Multiplying the polynomial by a constant from the field does not change this, so yes, you can do it and still be secure. In fact, in multiparty computation, something akin to this is done when we want to privately multiply ... 2 There is one subtle problem with your proposed protocol: unless$f$is restricted to commutative functions, the lottery can choose to reveal one of two values. Here's how he does it: the lottery selects$p1$and$p2$as per the protocol, and publishes$p1\times p2, f$. However, when it comes time to reveal the committed value, and the lottery sees that the ... 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

Because the function used for RSA encryption and decryption is commutative. This means that given secret key $sk$ and public key $pk$ for all messages $m$ you have that $$D(E(m,pk),sk)=E(D(m,sk),pk)=m.$$ This means that first encrypting a message with the public key and then decrypting the so obtained ciphertext with the corresponding secret key yields the ...

2

Lots of problems are hard to solve but easy to check. For example: finding hash pre-images of particular values such as 0 calculating discrete logs of small numbers modulo a prime finding the factors of a large composite of a special form like $2^p-1$ I don't think there's an essential difference between solving and checking they're just arbitrary ...

1

What you are looking for is explicitly specified in the IEEE Standard 1363.1 [1], which covers NTRU. In particular, encoding a bit string into a polynomial is done in the following manner: Once you have processed the input message, you divide it into blocks of 3 bits, and transform each block in a pair of coefficients of a ternary polynomial according to a ...

1

It's much easier to add a cost factor to the key derivation from the password than to add a lot of data to an encrypted container. See the PBKDF's PBKDF2, bcrypt and scrypt for more information, or see this Q/A for GPG. In general, an iteration to derive the key is of course much more efficient than adding overhead at the start of the file. If a key with an ...

1

I'm not aware of any implementations, but I'm also not aware of any patents on this algorithm. Furthermore, that algorithm can quite directly be made tweakable, as that paper describes on pages 10-13.

1

My implementation of Serpent is bit-sliced, so there is no initial permutation involved in generation of my round subkeys. It is also NESSIE byte ordered, which means that vectors will not match the AES submission package. I assume that IP will reorder the bits appropriately if you are using a non bit-sliced version. I just rewrote most of my implementation ...

1

The notation you are seeing is for symmetric crypto. Garbled circuits typically use symmetric crypto since it can and symmetric crypto is fast. You may be able to do garbled circuits with asymmetric crypto, but it is definitely non-standard and may have subtle issues.

1

When you are e.g. sending TLS encrypted data over a SSH tunnel, there are two things in particular that should be noted: The TLS handshake will only commence, once the SSH connection has been established. The bulk encryption keys of TLS will be completely independent of the SSH encryption keys. Since the handshakes and keys are completely independent, ...

1

Short Answer: Yes Long Answer: From what I understand about quantum computing, they are only more efficient as long as the bit-depth of the problem falls within the bit-processing capabilities of the quantum processor. Example: a 64-bit quantum processor could solve 64-bit traditional encryption keys in a near-zero real time. 128-bit keys would still take a ...

1

Typical scenario is to run the raw shared secret through a key derivation function to generate keys for any symmetric primitives they will use.

1

I guess because because foo.txt has a lot of redundancy and thus can be quite significantly compressed. Consequently, the compressed file foo.txt.zip is much smaller (you should take a look at data compression).

1

There's no particular computation you have to do. Since all other tables could be computed just by rotations of Te0 what you need is just to perform rotations, xors and table lookups. Here's what usually done when you have only Te0. You read the state column-wise, keeping in one 32 bit variable/register the value of one column. (As convention hereafter, ...

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