Tag Info

Hot answers tagged

11

I restrict to hash functions $H$ with an output of some fixed size $n\ge1$ bit(s), accepting as input some strings, including all $n$-bit strings; MD5 (resp. SHA-1, SHA-256) is an example of such function for $n=128$ (resp. $n=160$, $n=256$). Whether there exists a solution to $H(x)=x$ depends on the particular hash function. If $H$ is a random function (as ...


8

No, because even SHA-512 was considered overkill from a security perspective. It has 256-bit collision resistance, which is unbreakable. (The link is about keys but a similar argument applies.) If you think large quantum computers will be efficient, a 512-bit hash makes some sense, but even then a 1024-bit one wouldn't. A quantum computer requires ...


7

Informally, a signature scheme with message recovery is one where some or all of the message is embedded in the signature, allowing to conserve bandwidth when transmitting a signed message, compared to a signature scheme with appendix. Total message recovery A signature scheme with total message recovery [some sources make total implicit, e.g. the HAC ...


7

I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ...


6

There is no uniform permutation; there is a permutation uniformly chosen from the set of all possible permutations over $Z_2^{128}$. It is evident that AES is not a uniformly chosen permutation, since its permutation is fixed for any key. One can consider a family $\{AES_K\}$ of AES permutations under all possible keys $K$. Even if the key is chosen ...


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


5

No, since finding $a$ allows offline checking of passwords. $\:$ No, although I can't back this part up.


5

Under the assumption that $(K,\text{Msg})\to H_K(\text{Msg})$ is a secure MAC (be it HMAC or any other MAC), and $\text{Nonce}$ does not repeat and is of fixed size, both $H_K(\text{Msg}||\text{Nonce})$ and $H_K(\text{Nonce}||\text{Msg})$ are demonstrably secure, in the sense that an adversary not knowing $K$ can't distinguish either from random, even for ...


5

The Secure Hash Standard and corresponding FIPS-180/202 do not specify any hash to meet a security requirement above 256-bits (using a 512-bit hash). This is unlikely to change. SHA-2 was built with state and word sizes to meet the security requirements on commodity computers (x86 and Alpha), which use 32 and 64-bit maximum CPU word sizes for general ...


5

You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset. Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ...


5

The main difference is that secp256r1 is a prime field curve, while secp256k1 is a Koblitz curve. Koblitz curves are known to be a few bits weaker than prime field curves, but since we are talking about 256-bit curves, neither is broken in "5-10 years" unless there's a breakthrough. The other difference is how the parameters have been chosen. In secp256r1 ...


5

If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset ...


4

Adi Shamir's secret database of all primes is to cryptography venues what the Dahu is to French summer camps. For why, see the answers to this related question. The three other future work items in the quoted presentation are in the same vein (Breaking RSA-1024 with Fermat factoring; Breaking RSA-1024 using $1024 = 2*2*2*2*2*2*2*2*2*2$; Breaking RSA-1024 ...


4

Let's see: AES CTR + MAC: still good advice. His recommendation of 256-bit keys clashes with Schneier's (also 2009) recommendation of 128-bit due to the weaker key schedule with 256-bit keys. Neither choice is broken, however. HMAC-SHA-256 as MAC: still good advice. SHA-3 is still not finalized. 256-bit random UIDs: 256-bits isn't going to risk collisions, ...


4

See “format-preserving encryption” at WikiPedia. Depending on the size of the message space, one can get such a scheme by: sorting pseudorandom values, see section 4.1 of “Format preserving encryption”, or using this arbitrary-size scheme described in “Perfect Block Ciphers With Small Blocks”, or using swap-or-not as described in “An Enciphering Scheme ...


4

A key derivation function lets you derive keys from others. In this case I would use HKDF, which means using HMAC in a predefined way. Your key material is the keys $X$ and $Y$, so you can concatenate those to get the PRK for HKDF-Expand. An output key would then be $\operatorname{HMAC}(X||Y, \text{info} || \text{0x01})$, if the size of the HMAC is long ...


4

Like the other answers say, it does not always have to be the case. One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value.


3

The catch how ever is that if a small part of the file is given along with the location of that bytes from the beginning of the file we should be able to decrypt just that piece. Normal CTR mode encryption allows one to decrypt any block of the file independent of the rest, so no need to invent your own mode. With AES the block size is always 128 bits, ...


3

First secp256r1 is a random and secp256k1 is a Koblitz curve. So according to this article: Koblitz curves should be avoided, [...] as they does not have enough warranty on crypto analytic activity and effectively they are: Not part of NSA Suite-B cryptography selection Not part of ECC Brainpool selection Not part of ANSI X9.62 selection ...


3

The correction question you should ask about why various operations in RC4 (or, for that matter, any other cipher) are there would be "if I were to remove that, what would the impact be? Would this weaken the cipher in some way?" At your current state of knowledge, that may be a rather imponderable question, but it is still the correct one. I can try to ...


3

I don't believe he is answering the right question. You essentially asked "why are public keys so much larger than symmetric keys", and after his first sentence (which started to address the question, but was a bit vague), he tried to answer the distinct question "why are public key operations so much slower" (not that he got the details of that correct; ...


3

I don't know of a use of Lamport's scheme precisely as Lamport originally published it; however if we include generalizations of the idea (such as Winternitz signatures), then it has been used as the basis of Hash Based Signatures, such as this proposal


2

Small addition: You do not lose integrity when using encrypt-then-MAC. Since encryption is an injection, distinct plaintexts produce distinct ciphertexts, so plaintext forgery implies ciphertext forgery, which is hard if encrypt-then-MAC is secure.


2

You're on a middle path here, and the main question is: What do you want to hide? What can the attacker see before/after the change? The least secure one is: Just XOR the bit changes on the ciphertext and be done with it. The information theoretic property still holds: If the attacker has exactly $0.5$ chance of guessing a single bit, and it was changed ...


2

There are many techniques: e-cash (coin-based schemes) can achieve this; also systems that use tamper-resistant smartcards (e.g., Mondex, in the US). If you trust the tamper-resistance of the card, then it's easy to devise a protocol for stored-value cards that can provide this functionality.


2

By and large, his advice remains good. I spotted only two recommendations where I would have a slightly different recommendation: I disagree with his advice about client-server application security. My recommendation would be to use TLS, and just use it properly. I understand his concerns (it is complex), but my experience is that when developer build ...


2

If you only ever use a particular OTP block to encrypt one plaintext block, there is no way to decrypt it. However, with your approach anyone looking at multiple versions of the file will be able to tell which parts have changed. For example, if the file contained secret messages stored by users, it would leak the length of each message added. Maybe that's ...


2

Berlekamp-Massey is designed for the situation where you have observed $2n$ consecutive output bits from a $n$-bit LFSR. It doesn't work if the observed bits are scattered randomly, at random non-contiguous offsets in the stream. Information-theoretically, a minimum of $2n$ bits of output are needed to reconstruct the LFSR. Intuitively, this is because ...


2

Choose some 128-bit hash function, such as RIPEMD-128, and a way of randomizing it, such as this. The private key is either 60 uniformly random 128-bit strings s00,s01,...,s58,s59 and a uniformly random short salt or a seed to regenerate those. $\:$ For each i in {00,01,...,58,59}, vi is the result of hashing si 19 times. $\:$ The public key is the ...


2

Is there code or idea for doing this? As you did not specify what research you have done, or what you already know, I can merely guess. In case you haven’t done so yet, you could check on: A privacy-compliant fingerprint recognition system based on homomorphic encryption and fingercode template Minutiae Matching with Privacy Protection Based on the ...



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