Tag Info

Hot answers tagged

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


7

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


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

We simply have to trust this party because this scheme requires a trusted setup. We can use verifiable secret sharing, that allows the parties to check whether the shares they have obtained are consistent. If we do not want to have a trusted dealer who sets up the shares at all, we have to switch to dealer-free secret sharing schemes. See for instance, ...


6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...


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

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

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

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

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

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

Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance. Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...


4

Annex E.1 of RFC 5246 contains the following text which is a nice summary of the situation: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will ...


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


4

The current specification says that tracker GET requests specify the following variables: uploaded=... (bytes) downloaded=... (bytes) left=... (bytes) This is great for public trackers but is poorly designed for private trackers. The problem is that the numbers don't always add up as they should and this can be for several reasons. For example, you might ...


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



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