# Tag Info

8

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

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

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

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

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

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

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

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

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

2

I don't think the approach you sketched helps very much. If the server is compromised, the attacker can pretty easily modify the server-side software to log and record all the cryptographic keys, and then you haven't gained anything. Therefore, I don't think the approach you sketch is likely to be a great way to spend your limited software development ...

2

Note that it is probably technically impossible to meet your requirement that both secrets have to be revealed at exactly the same time, if interpreted literally. However, if we interpret this requirement as meaning that each party needs guarantees that the other party selected its own message, before decrypting the message of the other party, then this ...

2

You might want to start by reading Lessons learned and misconceptions regarding encryption and cryptology. I spotted 3 potential issues in your proposal that are explained there. Instead of designing your own cryptosystem, you should try hard to use an existing well-vetted scheme, like TLS or DTLS for interactive communication, or GnuPG for storage or ...

1

One problem not mentioned here is that CRC collisions are a certainty. If you were using a cryptographically secure hash, you would never encounter a false positive where both solutions were possible. In this scheme, every 256 messages would yield identical CRC values, and your different versions would be indistinguishable. You might be able to "stutter" ...

1

CRCs are not cryptographically secure. If you need cryptographic security, replace the CRC with a message authentication code (MAC). If you don't need cryptographic security, then your question is off-topic for Crypto.SE and you should probably flag it to ask the moderators to migrate it to Computer Science.SE.

1

r can only be reused by coincidence (i.e., it must be selected independently each time). There is not problem with giving multiple commitments to the same x. In the following, p will be the modulus and q will be the order of the group. Definition: $\:$ range(n) is the set of non-negative integers that are less than n The following conditions guarantee ...

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