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

5

I'd say that most of the time the signature is accompanied by the certificate of the signer. This certificate contains the public key. Most container formats such as CMS (used in S/MIME, also known as PKCS#7) or XML digsig contain specific fields that may contain certificates - and usually do. When the certificate is received the Public Key Infrastructure ...

5

Your requirements are not terribly precise, so here is what I think you mean: "The result must be trusted by all three participants" ==> Even if Alice & Bob are both malicious & colluding, the output of Carol should be uniform. Also, all 3 should get the same output. "The coin is flipped only by Alice and Bob" ==> Alice & Bob do all the work. ...

5

Short key fingerprints are indeed vulnerable. But those are different from the short-authentication-string (SAS) used by ZRTP. A simple SAS based protocol using one-time keys could look like this: Alice sends a (collision resistant) hash of her public key to Bob. Bob sends his public key to Alice Alice sends her public key to Bob The short ...

4

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

4

This protocol doesn't authenticate the mote at all. Consider this attack: Mote B sends a 'hello' message to Base. This message contains the ID# of Mote A and a random nonce [R] (HW generated) encrypted by the base's public key. Base decrypts the 'hello' and verifies the ID# against a whitelist. Base sends an 'ack' message. This message contains some ...

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

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

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

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

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

Normally, yes, the hash algorithm in use is communicated beforehand. For example, sending an algorithm identifier during the TLS/SSL handshake process. However, depending upon the "padding scheme" in use with RSA, it may be possible to determine which hash algorithm was used from the signatures themselves. Some padding schemes encode information ...

2

As fgrieu pointed out, Alice and Bob must have somehow come to some kind of agreement before the random beacon is generated. Would either of these techniques work for you? use the random beacon directly They could agree ahead of time that "Alice wins if the first random bit sent by the NIST Randomness Beacon on 2015-11-02 at 11:59 is a 0, and Bob wins if ...

2

You are describing a replay attack. The most simple method to prevent this is to include a message counter as part of the message, and reject any message with a counter equal to or less than the last message. The message counter should be large enough so that key changes would occur before the counter loops. A 32-bit message counter allows 100 messages per ...

2

How do cryptographic systems handle such situations? … What actually is done in real life? In real life, cryptography handles situations like the one you describe by using “authentication”. Authentication links an action, a message or a situation to an identity. In the example you describe, this will practically boil down to a validation of something an ...

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

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.

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