# Tag Info

7

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010. With stream ciphers, MAC-then-encrypt ...

6

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...

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

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

5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...

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

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

3

I may be interpreting your question incorrectly, but it sounds to me like you are asking if Caroline can prove (in court or whatever) that she can only gain access to some secret $S$ if both Alice and Bob collaborate in revealing it to her. Unfortunately as you have currently set up the question, I don't think that is possible, because your question ...

3

The "interesting" part of your encryption is here: Therefore, I prepend a block at the beginning of my packet. Its content goes as follows: First four bytes: current timestamp in seconds Next 12 bytes: zeros I compute the sha256 hash of the message (32 bytes) I xor the timestamp + zeros block with the first half of the hash I xor the ...

3

This is exactly where automatic protocol analysis tools can help you. For example, using the Scyther tool, the protocol description using symmetric encryption is: /* * Protocol description for Scyther * * Note we use 'K' to model 'k' since Scyther assumes 'k(.,.)' refers * to pre-shared keys between two agents. */ // The protocol description with ...

2

The answer to the first question is both. TLS uses a custom PRF based on HMAC to generate symmetric and MAC keys from a shared secret. The shared secret is created during the asymmetric key exchange between client and server as part of the handshake. The PRF generates key material of a required length. That length is determined by the key sizes and the key ...

2

One algorithm that is especially suited to one-use key pars is lamport signatures. Like many (all?) other signature functions, lamport signatures first hash the message to get it down to a size that is more reasonable to sign. For this use case, if you are willing to have $n^{2}$-bit signatures and $2n^{2}$-bit keys (public and private), you can sign a ...

2

The purpose is to prevent a two-for-one guessing attack, where an active adversary, impersonating the server, can test two password guesses per attempt. The attack and why the multiplier prevents it is described in Section 2 of the SRP-6 paper (ps). (According to MacKenzie, it was discovered by Bleichenbacher.) In brief, the attack goes like this: Instead ...

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

At one point, most music legally sold digitally was protected by DRM (all iTunes music, for instance). Eventually the labels backed down and started allowing the music to be published DRM-free. So yes the music industry has attempted this, but it encountered all of the fundamental problems with DRM and was abandoned. Crypto fundamentally can't protect you ...

2

It depends. If the entire input itself is within a DER encoded structure, then I would bug out. There is nothing defined for BER, CER or DER that would allow padding of structures within constructed values. If the input is just followed by additional data or junk bytes then it is up to the protocol or otherwise your discretion if you want to accept the ...

2

I don't think there's an exact "correct" behaviour in this case. It would be up to the implementation to decide, since the spec is only concerned about the DER encoded portion. If your implementation parses the input as it moves along only, and doesn't concern itself with the overall size, then it would work fine. Having said that, I believe the best ...

2

Not much in the cryptographic protocols themselves. But you can do other things to get around such attacks: Request signed read receipts, or received receipts. So, if I send a message from my phone to yours, it sends back a reply that your phone has received the message (or that you have opened it). If such a receipt is signed, your attacker might be able ...

2

Message sequencing AND hash-tabling for a trail of backward messages. The loss of a single message is not a disaster, actually. To be not over-paranoid, implement "resend request" in your protocol. If it works and hashes are matched - it can be just a communication error. But if it fails - a line should be dropped immediately. Try to use Tor by the way, and ...

2

It can guarantee the integrity, because you can not fake another voting with the same hash. However, this only shows the ballot is casted correctly, but does not prove the ballot is correctly counted. And as you said, it can not provide anonymity, such as buying vote and coercion.

2

Just to say you have tons of literature about that. If you need an entry point check out some papers here for instance: http://esorics2014.pwr.wroc.pl/page2/index.html#15 Read the introductions and the related work and follow the links to find the big seminal papers in the domain. Oh also, just a remark: it seems that you are looking for anonymity. if ...

2

They could use 1 out of 2 oblivious transfer. Alice offers the messages $0$ and $a$ and Bob uses $b$ as his choice bit (I.e., choosing the first message if $b = 0$ and the second if $b = 1$.). It should be easy to see that Bob now receives $a \land b$ (if in doubt write down the truth-table). Now Bob can send the result to Alice (or they can do the protocol ...

2

A self-made modification to CBC is a bad idea, since your "IV" will not be random enough, whereas it must be truly random for CBC. Stream cipher is a good idea. You may use AES in the Counter mode, or you could use Salsa20, or any other eStream portfolio cipher (software and hardware implementations are available for all of them). Ensure that you have ...

2

Dmitry's suggestion to use AES in counter mode sounds good to me, assuming that you only need confidentiality, and not integrity protection. (Counter mode, like most stream ciphers, is very malleable.) One trick you can use to save a bit of space is to use the current time as part of the nonce. (Of course, this only works if your devices have fairly well ...

2

The problem with the HMAC-based solution you drew up is if the shared secret $s$ has low entropy; for example, it's actually a password that could conceivably be in a dictionary. In this case, someone could listen to the exchange $r_1, \operatorname{HMAC}(C \mathbin\| r_1, s)$, and go through his dictionary of possible values of $s$, and see if any one of ...

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