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

7

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

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

3

If it is for completely random data you could still make a program that uses the random looking input to make different choices. For instance, you could sign two .jar files in Java, using the SHA-256 hash over the file in the META-INF folder. Then you can use the different files a property to make one choice or the other. Basically you're replacing one of ...

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

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

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

My question is how do I authenticate my App to the CA, to prevent something else to request these Client Certificates? There is generally no way to authenticate the client code. Any secret you embed in the app could be extracted. You must assume an attacker can send requests that an authentic client would. Instead, what you can do is authenticate the ...

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

3

With a hash function that is vulnerable to length extension attacks, like SHA-256, you can turn any random collision into a collision with that random string concatenated with some (partially) chosen data. In any use case where random initial data does not matter, you could use it to generate two documents which have the same hash value and thus the same ...

2

The protocol seems secure. Some comments below. Bob computes the DH shared secret X using his private key and Alice's static public key, and then K(X), the result of applying an appropriate key derivation function (KDF) to the combination of A, B, and X. The DH secret X already depends on both key-pairs. Including the public keys in key ...

2

Well, there is not much to prove. The server can do any change to $v$. So actually, this means the server with throw away your $v$ and just choose a new random number. Or alternatively, he chooses $w$ uniformaly random and sets $v'=v+w$, which is now also uniformly random. When you get back that value, you have your (for you known/fixed) values $a,b$ ...

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

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

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

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

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

The really important thing is, not encrypt-and-mac. The other two, you can debate, but both are at least theoretically sound -- one might just practically be better than the other. Encrypt-and-MAC falls apart for a very simple reason, though: the MAC is not meant to keep the plaintext secret. The MAC is based on the plaintext. Authentication is not designed ...

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

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

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

swap-or-not seems perfect for your use case.

2

A few approaches: Generic format preserving encryption. For example AES in FFX mode. The downsides of this approach are complexity and performance. Block-ciphers with small (typically 32 bit) blocks. Skip32 derived from Skipjack ipcrypt (very recent, no security analysis so far) The downside of this approach is that these ciphers aren't very popular ...

2

The usage of the r key forces both parties to "fix" the public DH keys. So Alice doesn't know Bob's public DH key before she's generating her own one. And Bob can not make the choice of the public key dependant on Alice's choice and vice versa. This forces both parties to be honest and to generate both public keys at random as there is no opportunity to ...

2

NOTE: My cryptography-based solution above (accepted answer) is my preferred method, but since it is significantly different I am including my old answer here (I did not want to clutter my other answer with it). Non-cryptographic solution: While the above extension to the BitTorrent protocol would require a lot more work, you can still nearly eliminate ...

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