Tag Info

Hot answers tagged

15

$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

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

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


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

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.


5

Designing your own crypto protocol (using existing primitives) is dangerous if you're not sufficiently familiar with cryptographic protocol design and the ways such protocols might be attacked. If you wish to gain such familiarity, I'd recommend taking a few introductory crypto courses that focus on protocol design and analysis.* This won't turn you ...


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

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

“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

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

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


3

In a rolling code both the sender and the receiver always move forward in the sequence. If the sender has sent the $n$th code, then it will send the $(n+1)$th next. Contrarily, if the receiver has seen the $n$th code it will only accept the $(n+1)$th code or some later code. What happens if the sender is at another point in the sequence? Think of that ...


3

I guess the answer is no, as long as you are using ECIES then this protocol does not work - you cannot trust the public key of Bob, which is required for ECIES. You could however use ephemeral-static Diffie-Hellman, using ECDH as cryptographic algorithm. Alice would supply the static part as her public key is trusted, Bob may use any key pair. That means ...


3

Are there any fundamental flaws? The construction itself is secure for a good H. It's close to what many stream ciphers use internally. E.g. chacha has an H that hashes a 256-bit key, a 64-bit nonce and a 64-bit counter to get 512 bits of output. Would it make sense to use a longer key? Yes, if you want more brute force resistance, since finding a ...


3

The biggest issue with padding oracle attacks are when the padding is not very carefully implemented (for example if using EtM you must calculate the MAC over everything - including the padding). To pre-empt references to the classic Belare-Namprempre paper, be wary - their results do not apply to modern primitives, since nowadays we prove security ...


3

Pairings in cryptography is a very important tool, the introduction of which has developed a new field, that is pairing-based cryptography. After the independent pioneering work by Joux and by Sakai et al.("Cryptosystems based on pairing"), many pairing-based crypto-systems emerged. In cryptography, pairings are often treated as "black-box", and then we ...


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


3

Asmuth and Blakley provided a proof that, assuming the keys for each cryptosystem are chosen independently, breaking their composite cryptosystem is at least as hard as breaking the hardest part of either. [1] Building on their work, cascade ciphers have been shown to in fact be harder to break than the hardest part of either. Admittedly, what you're ...


3

In your example, $Encryption_1$ is $\textsf{AES}_{CTR}$ and $Encryption_2$ is $\textsf{Salsa20}$. Then, the encryption method you are proposing is $Encryption_1(Encryption_2(plaintext))$, which is in fact a cascade of stream ciphers. Note that, because you simply XOR the streams, this cascade cipher commutes, that is, you will have the same result if you use ...


2

Yes, that is possible -- that's exactly the problem that secure multiparty computation solves. You should start by reading standard references on secure multiparty computation. You might enjoy the following paper, and follow-on work: Secure Multiparty Computations on Bitcoin, Marcin Andrychowicz and Stefan Dziembowski and Daniel Malinowski and Łukasz ...


2

Assuming this is "usual" HTTPS using SSL/TLS with RSA key exchange, the client generates a random secret, encrypts it with RSA (using the server's public key) and sends it to the server. The server then decrypts it (using its private key), and both generate from this (now shared) secret (and some public data depending on the messages) several keys which are ...


2

Why? We want to be able to build off of more basic encryption schemes. Suppose we use some stream cipher; then why can't we use Encrypt(m|H(m)) as the MAC-then-encrypted version of the message? For "traditional" non-authenticated encryption schemes, encrypting plaintexts with the same length always produces ciphertexts with the same length and for ...


2

…something like HMAC is used rather than a plain hash. HMAC is a keyed hash… which means it additionally provides unforgeability. A “plain hash” (which I assume to include cryptographic hashes) merely provides collision resistance, while a HMAC provides both collision resistance and unforgeability… because an attacker is unable to calculate a new, ...


2

It depends on exactly what protocol you're asking about. ECIES as design gives no assurance to Bob that the message really came from Alice. This is, with standard ECIES, Alice does not use her private key -- instead, everything that Alice does (encrypt using Bob's public key) could have been done equally well by someone else - hence, Bob has no ...


2

Choose a public key encryption scheme, where $(s(x||r), p(x||r))$ is a key-pair derived from $x||r$ using a cryptographic hash function so that $s(x||r)$ is invertible. To make a commitment $C(x, r)$, Alice derives the key-pair and publishes the public key $c = p(x||r)$. If she reveals $x$ and $r$ then anyone can see if the same key-pair can be derived: ...


2

If there is _______________ obfuscation scheme for such $\hspace{.03 in}f$s then there is a scheme that does what you describe, where _______________ is either "a differing-inputs" or "an extractability", depending on how you define "doesn't know Alice's secret". Note that if there is no a-priori bound on the length of $x$, then the $\hspace{.03 in}f$s ...



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