# Tag Info

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

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

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, … , X, Y, or Z. ($26$ possible letters.) For B you can use A, B, C, … , X, Y, or Z, but not the ...

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

3

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

3

Your key only seems to consist of n, which should be easily brute forced. So not very secure is the only answer that can be given. n could be very large (a 128 bit number or so), but in that case this scheme seems very inefficient. Please note the remarks on this kind of generator here and here. So even if it is secure, it may be very tricky to show that it ...

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

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

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

Since it's a linear cipher, you should be wary about a guessable padding, otherwise if your last block is only one char long, you will reveal almost your whole matrix on this last block. If you're too afraid of mangling the last word, use something like 'Z'+(random chars). But I really would not use any predictable padding with such a cipher.

2

I need a small clarification that why openssl using SHA1 in ECC when I am using secp384r1 curve, but in rfc they are saying we should use SHA2. OpenSSL uses SHA-1 because RFC 4492 defines the use of ECC on SSL with SHA-1. It should also support SHA-384 as defined in RFC 5289. Which hash algorithm is used in TLS depends on the cipher suite. For example: ...

1

There are two answers, really depending on your specifications and how your generator will be evaluated. If all you need is to have a PRNG with statistically excellent random, but really don't care about predictability or cryptographic considerations, go for something simple like a Mersenne Twister. If you actually need some effective stream-cipher, look ...

1

If your environment was fully compromised you could at no point actually decrypt your data, defeating the purpose. So I’m going to assume the user only uses an authentic client and the client’s memory is protected during execution. Generate a private/public keypair. Store the public key on the server, encrypt the private key with the user’s passphrase and ...

1

What you ask for is possible, but only (I'm pretty certain, although I don't have any sort of formal proof) if there is a central authority who has a separate, secured connection to each user. Also, the concept of public keys becomes unnecessary. If the encryption and decryption key is a function of "public keys", then any user who at any point was a member ...

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