# Tag Info

0

F can be evaluation of the degree-at-most-(N-1) polynomial over a finite field s at A. $\:$ N input-output pairs would allow one to efficiently find s by Lagrange interpolation. $\:$ Observe that for all A, evaluate-at-A is a linear map from S to the field. $\:$ Since Lagrange interpolation will always give a compatible polynomial (and not just find one ...

0

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

10

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

0

You can make incremental changes that only touch small pieces of the file faster, at a cost in complexity. Multiple hashes can help with that. Rather than a single hash value, you can amortise the cost of computation by storing multiple hashes. If you hash the large file in pieces, then you can create a single hash that covers the entire file by hashing ...

0

Your idea does not seem to provide any security benefit. If an attacker was able to modify the data while preserving the MD5 hash, your encrypted MD5 hash would also stay the same. One practicable aproach would be to simply use MD5 hashing. To tamper with the data without changing the hash, an attacker has to perform what’s called a second-preimage attack ...

-1

Play with SBOX in AES. The encryption using the standard one is faster than the decryption. If you search you can find one with your specifications.

0

DISCLAIMER: any implementation of the following should be reviewed and analyzed before being used in a non-test environment. I have tested an implementation that operates as expected for 32 and 64-bit inputs, but proper round counts have not been determined. Most modern block ciphers already use building blocks that operate on 32-bit integers as they are ...

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

0

We have designed FNR encryption scheme for this very purpose of preserving lengths and formats of small input fields ( $32 <= x < 128$ bits). It uses Naor and Reingold's PWIP extensions to classic fiestel networks. They have proved it to be more secure than classic Feistels. We have made it practical by using invertible matrices rather than working in ...

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.

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

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

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

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

In OTP you have $C=K\oplus{M}$. If the key is the same $C1=K\oplus M1$ and $C2=K\oplus M2$, => $C1 \oplus C2$ = $K\oplus M1 \oplus K\oplus M2$ = $M1 \oplus M2$ If you have the same ciphertext, that means that the same message was encrypted. E.g. messages 4,6,7,11 have the same first 6 symbols.

-1

As encryption scheme that could only encrypt fix length message is a important essence in cryptography, e.g. one-time pad. Block cipher is a better example, e.g. AES is a popular block cipher whose block size is 128 bits. While given such block cipher who could only encrypt 128-bit string, you can construct encryption scheme that encrypt arbitrary length ...

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 ... 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, ... 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 ... 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 ... 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 ... 0 What you are proposing is bad. RSA-KEM uses RSA encryption without padding, but not in the way you are proposing. See the second part of its Wikipedia Page The problem with your construction is that if you encrypt a short message (i.e. AES key) with RSA without padding, then it might get decrypted through e-rooth calculation or through Coppersmith. It ... 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, ... 0 From what I can tell about the FEAL family by doing a little bit of research, the inputs for the FK function are two 32-bit sub-keys, each of which are half of the 64-bit key. http://www.cs.rit.edu/~ark/spring2013/482/team/g1/report.pdf Contains some instruction on the FK function you are asking about. 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 ... 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 ... 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 ... 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 ... 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. ... 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 ... 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).

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

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

Top 50 recent answers are included