Tag Info

New answers tagged

0

Yes; virtually all of them. Quantum computers give a quadratic speedup on a general search problems (so key lengths need to double), but I don't know of any symmetric schemes in actual use for which quantum computation gives a bigger speedup.


2

It you need a deterministically derived key for AES, the DRBG algorithms of NIST SP 800-90A are suitable, and their output is directly usable as an AES key. An example use case is when computing an AES session key from a longer-term master key, and the nonce corresponding to that session. AES will expand its key (128, 192 or 256-bit) to 128-bit subkeys (one ...


1

Can it also be used as a one-time encryption scheme? You cannot build asymmetric encryption from just hash functions. There is an impossibility proof for that. So for asymmetric encryption the answer is no. For symmetric encryption, you can simply use the hash function directly to build encryption, no need to bother with Winternitz. But you could use ...


1

There's a lot of ways to attack this. The first thing to notice is that if you know the value of plaintext at index $i$, you can then deduce the value of all the plaintext bytes at index $i+8k$; for all integers $i$ (!). That's because the relation between plaintext and ciphertext bytes is $P_{i} = C_{i} \oplus P_{i-8}$; if you know $P_{i-8}$ (and, of ...


1

I would prefer to use standardized (like FIPS 140-2) secure random generator, since the whole point is to secure the encryption key. Of course, you might want to check this website for reference: http://www.cryptosys.net/rng_algorithms.html


2

First, don't roll your own crypto. Second, why would you want to use CBC-MAC, if you have GMAC (GCM-mode) and CMAC and even better HMAC? (all of which are better than CBC-MAC) Third, don't try to fix problems that have been fixed. (see second) Fourth, I'm not aware of this construction being standardized and I'd doubt it has been. (see points 1 to 3) ...


1

The stream cipher generates 128 key stream bits per iteration. Usually these bits are buffered internally. When the encryption or decryption (identical operation, encryption = decryption) takes place then the bits are taken out of the buffer and the plaintext at the same location is xorred with it. When the keystream buffer is exhausted the next iteration ...


0

Padding oracle attacks are targeting servers, where the padding oracle attack is performed to attack the encrypted connection between client and server. You use encryption only internally, without an external interface, so yes you are right: There is no interface, where an external attacker could perform this attack. However, your entire setup is flawed ...


2

Key stretching is only used to make small-entropy keys less vulnerable to brute force attacks. If it is (nearly) impossible to break the original key, than there's little sense in using a iteration count of more than 1. If the input to the function is as big (in sense of entropy in bit) as the output, then an attacker could just attack the algorithm which ...


7

In computer science, and implementation of crypto, ROTL stands for ROTate Left. ROTL is also noted ROL, or RLNC for Rotate Left No Carry. On a $w$-bit word with bits numbered from $0$, bit number $j$ of the input of ROTL with a shift count of $n$ goes to bit $j+n\bmod w$ of the result; $n=1$ unless otherwise specified (and is the only value available on ...


-1

It seems that you do want to be given the answer and not just hints, so I will do that. But I'll go step by step so that you can stop reading if you want to finish by yourself. It seems to me that both solutions satisfy the first requirement consisting in authenticity. Breaking this property would consist in changing the content of $R$ to fool $A$ (this ...


1

The "significance of inside attacker or threat" is making the problem non-trivial. We "should we care about it in this case" because the protocol apparently claims to provide some sort of revocation.


1

My own two cents on this is that it started with a psychological bias, due to the illusion that AES-ciphering consecutive numbers in CTR mode is a weakness compared to the recursive AES-ciphering in CBC. Actually, I think I remember it was more of less told during that course on Coursera, that a consensus about the inoffensiveness of that counter with regard ...


1

It seems you want some sort of anonymization, and you already jump to a conclusion with encrypting symbols. Maybe you should step away of that for a moment, and ask yourself what your actual goal is. Encryption is useful, if you want to be able to reverse that process. If you don't hashing is a better choice in general. Your set is small enough that you ...


0

I'm not exactly sure why you are doing what you're doing so my answer may be off-base but I have a couple of ideas. First, being that you're using ASCII to store the data, use more than the 10 digits. Let's also say that we'll use A to mean 0, B to mean 1, through J to mean 9. When you convert to integers, always replace the first digit with the A-J ...


2

As far as I can tell, you just have encrypted data in a DB and are worrying that it can be hacked. In short, encryption works so you're good. In more detail, your analysis of a padding oracle attack is correct. As you don't have any services or APIs or network protocols that partake in the encryption, a padding oracle attack can't occur. Understanding ...


1

Apart from the performance hit of encrypting / decrypting twice, and the inconvenience of having two keys to not lose, this should work fine. In fact I wish more people had your approach to data privacy and encrypted things before sending them over the internet! About Altdrive in particular, a good question to ask yourself about their upload service / ...


0

Shouldn't be a problem. There's a performance hit, of course. A usability one as well. And, of course, don't lose your key. That said, I think that AltDrive is secure. They state "You can choose to manage your own encryption key so that no one, including AltDrive personnel can access your data."


13

Decrypt the ciphertext with every possible key and store the result: $2^{56}$ decryptions. Now encrypt the (known) plaintext of the ciphertext with every possible key: $2^{56}$ encryptions. Now you have to check every entry, which is in both lists and try it with another plaintext-ciphertext pair. If you can successfully decrypt that, you are very likely to ...


2

When we have regions of the packet that we only authenticate but not encrypt, that happens because we have data that we want to bind to the encrypted region, but we don't need to include within the encrypted region. Examples of this are: For IPsec, we include the sequence number (as a part of the ESP header). We include that within the authentication ...


3

There are no security advantages to evaluating the polynomial at random places instead of sequential. The information theoretic security proof of Shamir secret sharing does not depend on the evaluation points being chosen in any specific manner.


2

The quoted passage of the Wikipedia article is wrong does not at first reading seem to match Blowfish as in Bruce Schneier's Description of a new variable-length key, 64-bit block cipher (Blowfish) (in proceedings of the first FSE conference, held Dec. 1993) which for this same operation reads: XOR P1 with the first 32 bits of the key, XOR P2 with the ...


3

The standard for full-disk encryption (FDE) is XTS mode or ESSIV-AES-CBC. XTS tweaks each block within each sector differently (and hence avoids ECB's problems) and is considered the best choice available at the moment. ESSIV-AES-CBC works by using AES-CBC with the IV being the hash of the sector index. The problem with this mode is that you can flip bits ...


1

The "logic" of the Enigma machine and the development of the Polish solution, in principle, are well described in David Kahn's "Seizing The Enigma". There may be better descriptions that have come out since, but I found this very clear and continue to recommend it. In addition to the nuts and bolts of the machine itself, Kahn describes the history from ...


1

I think you will not find any scheme that works over $Z$. But, if you want to work over $Z_t$, you just have to choose a LWE-based encryption scheme that encrypts non-binary messages, and there is a lot of them! For example, the paper ML Confidential uses one scheme like that (non-binary messages) to perform classification algorithms over cipher texts. ...


1

Consider what it means for a key $k$ to be chosen according to some distribution over key space $\kappa$: Assume that $\mathsf{Gen}$ picks key $k$ from key space $\kappa$ with probability $p$. Since $\mathsf{Gen}$ is randomized, this means that a $p$-fraction of all the random tapes will lead it to generate $k$ as the key. If we now conceptually redefine ...


5

Sorry for the late answer, I got busy... So, you know that $\mathsf{Gen}$ is a probabilistic algorithm. What's a probabilistic algorithm? It's an algorithm which, during its execution, can make some random choices, which can be modeled as coin tosses. In programming terms, the algorithm can use a special coin-tossing function, which returns $0$ or $1$ each ...


3

Pros of encrypting entire payload: That's simplest to code. Encrypting data may have the side-effect of improving the chances to detect an alteration during transfer of the cryptogram (hence enciphering the whole payload may extend that beneficial side-effect to the whole payload); however that is not the function of encryption, and it must not be assumed ...


3

If you just need random numbers, there's no point in generating random primes. Just make sure that you're using a cryptographically secure random number generator, properly seeded from a secure entropy source. Also, passwords made up of random letters and numbers are very hard to remember (and type). For a password meant to be memorized by a human, it's ...


2

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ...


0

As far as I understand the question, you ask how a (client-)certificate is issued and generated. Normally this works like this: Get an account at the page of the CA. (this is important in later steps) Validate your identity against the CA, f.ex. using documents like driver-license or passport. Your account will then be listed as "verified as owned by XYZ" ...


0

First: use rather ECIES or some other IND-CCA2 safe variant. If this is a theoretical question you need to know, that any plaintext (a number) must be smaller than $p$. To reach this the bitlength $log_2(m)$ must be smaller than the bitlength $log_2(p)$. Now you can only encode the data as bytes(256 values), so we are switching from base 2 to base 256 and ...


0

I did the procedure myself, and I can confirm that base64 decoding will do the trick; the full decrypted file will have == at the end somewhere. After decoding, the "file" command will reveal the plain text type. The '.uyu' file is quite easy to "decrypt" as well, I noted.


0

If I'm understanding things correctly, you want to make sure that the public key you receive actually belongs to the person you want to communicate with. Thus you want to avoid MITM attacks, which is non-easy. Standard (TLS/S/MIME/...) solution would be to create a certificate signed by someone you trust to assure you that the particular public key belongs ...


2

openssl rsa -pubin -inform PEM -text -noout < public_key.pem Public-Key: (64 bit) Modulus: 16513720463601767803 (0xe52c8544a915157b) Exponent: 65537 (0x10001) The modulus is small enough that you can easily factor it After finding the prime factors, you can calculate the private exponent After you have the private exponent, you raise each 64-bit block ...



Top 50 recent answers are included