# Tag Info

14

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

11

I assume the question is related to academic work: why do we implement a protocol if we already know how efficient it is by a complexity analysis? The answer depends very much on the type of protocol. However, the answer typically is that a theoretical complexity analysis usually does not suffice to understand the concrete efficiency. If the "previously best ...

10

Do we implement it for proof of concept? Absolutely. It's very easy to miss vital points if no implementation exists. W3C for instance doesn't even allow protocols to be standardized without reference implementation(s). Furthermore, an implementation may show small improvements as well. Personally I would require an implementation of all the (minimal) ...

8

You're describing a form of three-pass protocol, which is a communication mechanism where neither party needs to know each other's secret key. Wikipedia describes a helpful metaphor using a box that can be locked by two padlocks: First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends ...

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

Given $v_1$ and $v_2$, can the server learn anything about $a$ and $b$? Yes, they can (with high probability) determine whether $a = b$; if $v_2 = 0$, then either $r_1 = 0$ or $a = b$; given that $r_1 = 0$ occurs with probability $1/p$, the attacker can conclude that $a = b$. Now, that's the only thing the attacker can learn; for any observed $v_1, ... 6 Even after your updates, the first part seems unnecessary. However, steps 4-5 do indeed prevent the attacker from learning future nonces they could ask the key MAC values for. So the protocol steps 4-7 would be secure with a secure MAC. I agree with CodesInChaos that using HMAC would be better, because H(m||k) has some weaknesses, while HMAC is standard. ... 6 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 ... 6 My only idea is that B authenticates himself to A, because if A later decrypts it, A will see whether B was able to decrypt it. But why would you need to increment the nonce? Correct, that's the idea. If B didn't need to increment the nonce and just encrypted the same value, the message sent back would be the same that A sent, so an attacker would be ... 6 Unfortunately, the answer to your question is yes. You have made glaring mistakes. In particular, Yao's garbled circuits are suited for two-party computation only, and here you wish to carry out a multiparty computation. One huge problem that arises with your entire approach is that if the server colludes with one of the voters, then they can learn the ... 5 Should we sign-then-encrypt, or encrypt-then-sign? ... Do the same issues with (symmetric-key) MAC-then-encrypt apply to (public-key) sign-then-encrypt? Yes. From a security engineering standpoint, you are consuming unauthenticated data during decryption if you mac-then-encrypt or sign-then-encrypt. A very relevant paper is Krawczyk's The Order of ... 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 There are many ways of doing this. A very nice read (but with informal presentation) is this paper by Fagin, Naor and Winkler on Comparing Information without Leaking It. A very fast protocol exists which requires a single oblivious transfer for every bit. Let$n$be a security parameter; say$n=128$, and let$\ell$be the bit-length of the inputs. For ... 5 Is there a protocol that A and B can use to find out the same thing without having to trust the other and any third parties? There is. Even more than one. Your problem actually is equivalent to Yao's Millionaire's Problem. You have two numbers which two parties want to keep secret and you want both parties to find out whether the one is larger than ... 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 ... 4 You can use any library you like, as long as it is has been tested for the specific algorithm. In other words, if$G^x$is implemented in a specific library you must make sure that there are unit tests and if it is used in a verified algorithm. There are some hints you can take from the library to see if it was programmed well: the code should point to ... 4 First up: it does use public keys in contrast to your claims. To be more specific –$q$is Alice’s public key, and$f$is Bob‘s public key. Both are transferred in public and might be intercepted by a MITM. This brings me to the next point: the system you worked out in your head is highly insecure. We'll call the message$p$and encode it as a number. ... 4 This is an extension of @SEJPM's answer. I want to expand on what protocols are best to use (I apologize ahead of time for self citations). First, for details on Yao's protocol, see A Proof of Security of Yao's Protocol for Two-Party Computation. However, to do this very efficiently, you need to have two very efficient components: A fast garbling scheme: ... 4 TL;DR: Find the most important specification that is of the same type as the one you want to write and use its style for yourself, chances are, other people also have read it. There is a myriad of ways to specify a crypto protocol / design. However, there are four things that you really should take into consideration when writing a crypto-related ... 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

I'm not sure I understand your question entirely. If there is only one possible message, then the ciphertext can be trivially decrypted simply by choosing this message. I'll assume instead that the ciphertext contains the shuffled bit pattern of a name chosen from a set of more than one name. The problem with bit shuffling is that the number of set bits ...

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

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

An algorithm which is secure even if the enemy acquires everything but the key may be regarded as a means of generating secure algorithms. If one presently has a secure channel for communicating with a correspondent, and will need to communicate securely in future when no secure channel is available, using some dice to generate a random key and conveying it ...

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

3

No, this will not work, for two fundamental reasons: You cannot "encrypt with the private key and decrypt with the public key" in any meaningful sense.* And if you could, it would be totally useless, because the public key is, by definition, public — if you could decrypt with the public key, so could anyone else. In particular, in your scheme, ...

3

This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it ...

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