# Tag Info

## Hot answers tagged protocol-design

12

Actually, that wikipedia article you mention in your question already answers your question: It is moderately common for companies and sometimes even standards bodies as in the case of the CSS encryption on DVDs – to keep the inner workings of a system secret. Some argue this "security by obscurity" makes the product safer and less vulnerable to attack. ...

11

I'll comment only the statement referring to an AES-256 replacement with 4096-bit key: According to our engineers, this will take 23840 times longer to crack than aes256 Bob writing that is not able to correctly transcribe even the numbers that engineer Alice allegedly spelled: most likely, $23840$ is intended to be $2^{3840}$, which is the ratio ...

9

First of all, if your goal is to keep the garbled messages to "once every hundred years", well, you already don't meet that goal, even before the change. With an 8 bit CRC, a random change has a probability 1/256 of being accepted; hence if your wireless network has a transmission error at least once every three months (which, to me, sounds like an ...

8

This is actually to a great extent a question of terminology, and ultimately which security claims you are prepared to make, more than it is a practical question. For short: You may draw the line between the key space and the algorithm any way you want, but the way you draw that line will have implications regarding which security claims you are able to ...

7

It depends upon what trust you have in the cloud. If you don't trust the cloud provider, a malicious model (treating the cloud as malicious) might make sense. The so-called "semi-honest" threat model almost never makes sense in practice. It amounts to assuming that someone is malicious ... but not malicious enough that they'll deliberately, actively try ...

6

Yes, this is a perfectly secure solution. The principle drawback is that the precision available is limited by the round-trip time to the trusted time server. If the trusted time server is 50ms away (i.e., 100ms round-trip time), which is a plausible situation that might arise in real life, then you cannot synchronize the client's time to within a ...

6

ElGamal appears to be used instead of Diffie-Hellman (or IES) in OpenPGP mostly because when that format was put together, there were some unresolved intellectual property issues surrounding both RSA and Diffie-Hellman, while ElGamal was unproblematic. This trend for ElGamal seems to stick around, mostly by force of habit, e.g. when switching to ...

5

TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...

5

Yes, your scheme is fine. Nitpick: I think you mean that your goal is to generate a random number in the range $0\ldots n-1$ (not $0\ldots n$). Also, to avoid bias, you need to generate $m$ as a random number in the range $0 \ldots (\lfloor 2^{256}/n \rfloor \cdot n)-1$ (not $0\ldots \lfloor 2^{256}/n \rfloor \cdot n$). This problem is known as secure ...

5

This started as a comment to @Poncho's fine answer, and grew over the 600-char limit. Point is: a careful choice of the definition of V2 messages can keep some the existing capabilities of the original CRC to always detect some kinds of errors. Foremost, we are interested in short error bursts (where all bits in error are within a small number of ...

5

When publishing the algorithm other people can review your algorithm and design. With this they can find flaws in your design and therefore improve this. The principle behind this is simply that many eyes find more errors than two eyes. Why do you think does the NIST review new candidates for cipher suites (AES)? This is to improve the security by having ...

5

I think it is still possible to use UC in this case. Recall the setup for the UC framework. We have an ideal world and a real world. There are parties $P_1,\dots,P_n$ in each world and an environment $\mathcal{Z}$ in each. In the real world we have the adversary $\mathcal{A}$ while in the ideal world, we have an ideal functionality $\mathcal{F}$ and a ...

5

You should encrypt the data using a well-vetted standard, like TLS (for data in motion) or GPG (for data at rest). Designing your own is more likely to lead to sadness. The format of the data that you protect in this way is up to you and can be broken down into structs and chunks and headers etc. to your heart's delight.

5

This is pretty much the schoolbook implementation of a shared random number generation (generate, commit, publish). So yeah, it's secure. But this only works for large random numbers, here's a small adaption that allows for arbitrary size integers: If you need an $n$-bit random number everyone should generate $n$-bit random numbers - this is independent of ...

5

Given: The attacker can call PRP() and the inverse function prp() on any message of his choosing. PRP is a pseudorandom permutation indistinguishable to the attacker from a random permutation. Assuming R and K are "sufficiently large", perfectly random, and never leaked to the attacker -- in particular, during a chosen-ciphertext attack, the decryptor only ...

5

QKD aims at exchanging key material to be used with encryption based on OTPs between two parties and thus to achieve perfect secrecy for transmitted messages. There are, however, several drawbacks for practical use in a wired setting of QKD (required hardware and their vulnerability to hacks, limited distance which does not support end-to-end ...

5

This is a classical example. Here is the proof system… Bob gives two gloves to Alice so that she is holding one in each hand. Bob can see the gloves at this point, but Bob doesn't tell Alice which is which. Alice then puts both hands behind her back. Next, she either switches the gloves between her hands, or leaves them be, with probability $1/2$ each. ...

5

RFC 6176 lists four reasons why SSL 2.0 must not be used, in its section 2: Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would ...

4

If you are using Cloud processing service subject to US jurisdiction, and your data is about a non-US person located outside US (i.e the rest-of-the-world), then FISA Amendment Act 2008 1881a authorizes coercion of Cloud provider in secret mass-surveillance from inside the datacentre. This was new - previous FISA was for interception of telcos/ISPs, but ...

4

Yes, $p$, $g$ and $h$ are system parameters. $g$ and $h$ only need to generate large prime subgroups of $\mathbb{F}_p^{*}$, and the equation $p=2g+1$ is not required. (In fact, if I understand what you mean correctly, it does not always suffice as $-1/2$ has the same order as $2$) It is important that $g$ and $h$ not be related by a known equation of the ...

4

It will depends a lot on what kind of customers you're expecting, and what kind of contract you'll have with them. If you're planning to store information that can't be leaked, at any level, because you told your customers so, well... you can't trust any provider, be it "honest", "semi-honest" or any other category. Think that someone can attack the ...

4

Private Set Intersection How about a private set intersection protocol? The banks input is a set of all of their account numbers, the user's input is their account number (a single member set). The output could be given to the user, or the bank, or both, depending on your needs. You would need a way to protect against guessing account numbers. For ...

4

I am assuming that the vault shall store arbitrary-length messages and associate with each message a token consisting of six decimal digits. Otherwise, as has been noted (see below), the problem is probably either impossible or trivial. I interpret your requirements to mean that the detokenization algorithm is also available to an attacker that has gotten ...

4

The claims made are pretty much all nonsense or do not represent an accurate understanding of the state of the art. I'm not going to go into a point-by-point response; suffice it to say that I would not trust any advice or representations they may make about what is or isn't secure. Their system might be fine, or it might not be, but their public ...

3

Since you do not describe why TLS Handshake and IKE are appropriate in your situation, and as long as you don't describe your situation, it's hard to really help you. Also, you haven't stated if it's only IKE that's not appropriate, or if that also includes IKEv2 (which improved the IKE protocol). Therefore, I'll simply assume you meant both. As an ...

3

There are many standardized key derivation functions designed specifically for this purpose. It would generally be better to use one of those rather than rolling your own. For example, HKDF (RFC 5869) should work nicely for your purposes, and it's versatile enough to let you also derive any other key material you might need (e.g. for message ...

3

To begin with, some essential requirements are missing from your question at the time I write this, so I am going to assume: $User$ trusts $System$. $System$ trusts that $User$ will not pass $Key_{User}$ to any entity that $User$ does not trust to be $System$. This implies, in particular: $System$ is already authenticated to $User$, and $User$ ...

3

I think what you want to look at is "fair exchange". There's a giant catalog of protocols for fair exchange. They've been designed for doing exactly what (I think) you want. See, e.g., https://en.wikipedia.org/wiki/Multi_party_fair_exchange_protocol Alice trusts Bob only when Bob trusts Alice Some fair exchange protocols require a third party who ...

3

First, a hash does not provide integrity. You would need a MAC (like HMAC) or a digital signature to ensure the message hasn't changed in transit. You'll have to put some standard value (say all zeros) into the field which holds the MAC, compute the MAC, then insert the value. Otherwise you have a chicken and egg problem. You need the MAC value to compute ...

3

Well, the obvious answer to 'how to find a Safe prime that is also a Nothing-Up-My-Sleeve' number would be to take one of the primes listed in RFC 3526. These primes (which come in several sizes) are all of the form $p = 2^n - 2^{n-64} - 1 + 2^{64} \cdot ( \lfloor 2^{n-130} \pi \rfloor + i )$, where $i$ is the smallest nonnegative integer such that both $p$ ...

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