# Tag Info

13

$Encrypt(m|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext. Here is a simple example with $Encrypt$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to sign some message $m$ of his choice. ...

11

I'll comment only the statement referring to an AES-256 replacement with 4096-bit key: According to our engineers, this will take 23840 times longer to crack than aes256 Bob writing that is not able to correctly transcribe even the numbers that engineer Alice allegedly spelled: most likely, $23840$ is intended to be $2^{3840}$, which is the ratio ...

9

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car. In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received ...

7

ElGamal appears to be used instead of Diffie-Hellman (or IES) in OpenPGP mostly because when that format was put together, there were some unresolved intellectual property issues surrounding both RSA and Diffie-Hellman, while ElGamal was unproblematic. This trend for ElGamal seems to stick around, mostly by force of habit, e.g. when switching to ...

7

As @D.W. guessed, the branching program for a circuit essentially reveals the original circuit. It's not clear what you mean by "apply the whole obfuscation process to the circuit-revealing branching program," but the prospects for that do not seem good: evaluating the branching program is highly sequential (polynomial depth), and you would need to ...

6

We simply have to trust this party because this scheme requires a trusted dealer (a party that distributes the shares to the secret to the participants - this can be you or some other party - but if its you you should trust yourself). We can use verifiable secret sharing, that allows the parties to check whether the shares they have obtained are consistent, ...

6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

5

This is a classical example. Here is the proof system… Bob gives two gloves to Alice so that she is holding one in each hand. Bob can see the gloves at this point, but Bob doesn't tell Alice which is which. Alice then puts both hands behind her back. Next, she either switches the gloves between her hands, or leaves them be, with probability $1/2$ each. ...

5

QKD aims at exchanging key material to be used with encryption based on OTPs between two parties and thus to achieve perfect secrecy for transmitted messages. There are, however, several drawbacks for practical use in a wired setting of QKD (required hardware and their vulnerability to hacks, limited distance which does not support end-to-end ...

5

When they write “well-typed”, they’re simply stating that the process $P$ is well-typed in context, or type environment. (Where the type environment contains a set of type assumptions occurring in $P$.) Keeping it simple: you can think of the term as a kind of classification. The term origins in Type Theory and is (more-or-less frequently) used in relation ...

5

For the moment assume $g$ is a secret (uniformly random) generator, but that $p$ may be known to the adversary. Then given only $g^a, g^b$, the Diffie-Hellman key $g^{ab}$ is information-theoretically uniform (up to small statistical error), i.e., it cannot even be found by brute force because the adversary does not have enough information to determine it. ...

5

You should encrypt the data using a well-vetted standard, like TLS (for data in motion) or GPG (for data at rest). Designing your own is more likely to lead to sadness. The format of the data that you protect in this way is up to you and can be broken down into structs and chunks and headers etc. to your heart's delight.

5

This is pretty much the schoolbook implementation of a shared random number generation (generate, commit, publish). So yeah, it's secure. But this only works for large random numbers, here's a small adaption that allows for arbitrary size integers: If you need an $n$-bit random number everyone should generate $n$-bit random numbers - this is independent of ...

5

Given: The attacker can call PRP() and the inverse function prp() on any message of his choosing. PRP is a pseudorandom permutation indistinguishable to the attacker from a random permutation. Assuming R and K are "sufficiently large", perfectly random, and never leaked to the attacker -- in particular, during a chosen-ciphertext attack, the decryptor only ...

5

RFC 6176 lists four reasons why SSL 2.0 must not be used, in its section 2: Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would ...

5

The current specification says that tracker GET requests specify the following variables: uploaded=... (bytes) downloaded=... (bytes) left=... (bytes) This is great for public trackers but is poorly designed for private trackers. The problem is that the numbers don't always add up as they should and this can be for several reasons. For example, you might ...

5

Assumption: the normal user can read the message, which is displayed on his screen. Generic attack: the user uses a camera to take a snapshot of the screen when the message is displayed. And voila! What you seek is demonstrated to be impossible.

5

No, this protocol does not provide perfect forward secrecy. Record the initial key transport message (shared via RSA-OAEP). If the attacker later gets access to the corresponding RSA private key, and decrypts the original key transport message, the entire symmetric key evolution sequence for that session will trivially unfold.

4

“Well-typed” relates to a type system. This is a general concept in computer science, the usage here is an example of the general concept and is not specific to cryptography. “Well-typed” does not refer to a cryptographic protocol, but to a theory (model) in which a protocol is described. A type system is a way to assign properties (called types) to ...

4

I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure: In the case of Skein and Keccak it should be secure. However, both of those have defined their own cipher modes which you should IMO prefer. (For speed and compatibility, if not security.) The Skein one is defined in section 4.10 of the ...

4

I am assuming that the vault shall store arbitrary-length messages and associate with each message a token consisting of six decimal digits. Otherwise, as has been noted (see below), the problem is probably either impossible or trivial. I interpret your requirements to mean that the detokenization algorithm is also available to an attacker that has gotten ...

4

The claims made are pretty much all nonsense or do not represent an accurate understanding of the state of the art. I'm not going to go into a point-by-point response; suffice it to say that I would not trust any advice or representations they may make about what is or isn't secure. Their system might be fine, or it might not be, but their public ...

4

Use the exponential variant of ElGamal, where the plaintext is encoded in the exponent. Elliptic curve ElGamal is fine. In fact, any public key cryptosystem which allows raising ciphertexts to a power such that this operation corresponds homomorphically to multiplication for the plaintext. Your commitments are $c_x = \mathsf{E}(x)$; $c_y = \mathsf{E}(y)$; ...

4

Two things going on that together may make plain-hash-then-encrypt insecure. First, the distinction between secure MACs and hashes, which is that a hash function may allow you to derive $H(m')$ from $H(m)$ even if you only know how $m'$ and $m$ differ. Length extension attacks on SHA-1 and SHA-2 are a practical way that can happen, but there could be others ...

4

I would say there are three general areas of necessary expertise for most crypto-related jobs: Knowledge of primitives and their use cases. Knowledge of protocols and understanding how to reason about their security. Deep and abiding understanding of how incredibly stupid people are, including oneself. The most that knowing the math is going to do for ...

4

Canetti ("Towards realizing random oracles," Crypto 1997) gave a reasonably efficient (very efficient, by the standards of most obfuscation work) "virtual black-box" obfuscator for "point functions," i.e., functions of the form $I_x(y) = 1$ if $x=y$, $0$ otherwise. Such functions can be used, e.g., for password checking. Virtual black-box obfuscation ...

4

I would generate this key, then encrypt it in such a way that it would take years (but not decades!) to crack, then release it publicly. Yes, you are in effect putting the master key in a time capsule. The problems of time capsules in general apply: the release time will not be exact and a breakthrough in e.g. CPU design could hasten it. If no one's ...

3

In here, it is 1-2 oblivious transfer meaning that for each $i$, the receiver gets $A'_{i1}$ or $A'_{i2}$ but the sender does not know which. The length of the elements $A'_{ij}$ is not important as long as you choose a correct oblivious transfer protocol.

3

The answer depends on how you would layer the encryption on top of the existing protocol. If you implemented your own Skype client, you could deal with compression issues yourself. That might allow you to use format preserving encryption, perhaps on the compressed data stream and not the audio itself. However, you would need to be careful – speech ...

3

If you want $N$ serial numbers, your serial numbers will have to use $n$ bits for uniqueness, where $n = \log_2 N$. So if you have 100 bits to use for the serial, you could use 20 to get about a million serials and have 80 bits to use for a cryptographic MAC or signature. Now there are two approaches, the symmetric and the asymmetric. In the symmetric ...

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