63
These decisions are driven by silicon. Most specifications for hardware are built around a minimally viable CMOS implementation (ex: MPEG-1, lightweight cryptography via NIST 8114). This is particularly true in commodity parts, such as cell phones.
When you make wireless ICs, you have two clocks in the system at a minimum, which are the carrier frequency ...
60
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. ...
55
This is known in the cryptographic literature as "traitor tracing". See, e.g., the following seminal paper:
An efficient public key traitor tracing scheme. Dan Boneh and Matt Franklin. CRYPTO 1999.
They show a public-key encryption scheme where each possible recipient has their own private decryption key. If an authorized recipient discloses their ...
52
Alright, I'll bite.
First, let me propose bounding the discussion to just the core of the protocol.
In particular, let's not get hung up on:
Social engineering attacks
How broadly the end-to-end encryption is applied (i.e. are all conversations in the app encrypted?)
The backgrounds of the inventors and reasoning for inventing the protocol
Metadata ...
44
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 ...
35
$\operatorname{Encrypt}(m\|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext.
Here is a simple example with $\operatorname{Encrypt}$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to forge an ...
33
No, it is not a good idea to hash phone numbers. There are only a limited number of phone numbers, so it is pretty easy for an adversary to try and hash all of them. Then you can simply compare the hash of each with the stored hash. Generally you don't have to deal with all telephone numbers, only a subsection of phone numbers anyway (for a specific country ...
29
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. ...
24
What happens if the sender is at another point in the sequence? ...
the key is pressed while out of range to the car.
In a rolling code (code hopping) system,
the keyfob transmitter maintains a synchronization counter C,
incremented every time a button is pushed.
The car receiver stores the most recent
validated synchronization counter it has received N.
...
23
Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle:
if you have to perform any cryptographic operation before verifying
the MAC on a message you’ve received, it will somehow inevitably lead
to doom.
He also demonstrates two attacks which are possible because of trying to ...
21
Generate a file of cryptographically strong random data at least as long as the message to be sent. This will allow communicating the secret using the random data as a one-time-pad. I.e., produce the ciphertext by using a bit-by-bit combining function such as XOR.
Purchase a plane ticket for an international flight connecting through Sheremetyevo airport.
...
17
Solutions to Yao's Millionaire's Problem should suffice for this computation. In that setup, there are two parties each with an input. The output reveals whose input is larger, and nothing else.
So Alice and Bob just run the protocol with their respective inputs A and B.
17
This is one of the earliest questions that was asked in modern cryptography. There is a proof that you cannot achieve completely fair contract signing. However, there are some reasonable alternatives. There is one direction called "gradual release" which I personally do not like. A model that I think has a lot of promise is called the "optimistic model". In ...
17
I heard of DRM but could not get a reliable implementation of DRM
There is a good reason for this: DRM is a hard problem, and a solution to it could be leveraged to obtain incredible amounts of money. Doing a cursory search for "why DRM doesn't work" yields an abundance of articles explaining the whats and whys.
To win at DRM, let's say you have some piece ...
15
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 ...
14
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 ...
14
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 ...
13
I think Encrypt-then-MAC does not deliver Plaintext integrity, but only ciphertext integrity. If the MAC over the ciphertext is OK but then we use the wrong key to decrypt (for whatever reason), then the recipient receives a plaintext that the sender did not send and did not vouch for. If this can happen, this is a violation of plaintext integrity.
So, ...
13
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 ...
13
In general, you cannot prove lack of knowledge, because even if you did know something you shouldn't, you can always pretend that you don't know it and carry out the proof as if you didn't know it.
For your specific example, consider how the prover would know $x_0$. Did you tell them what it is? If so, that proves nothing, since they would then know $x_0$ ...
12
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 $2^{...
12
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 ...
12
Disclaimer: I use Coq on daily basis...
About the tools
As you are looking for a formal verification, I would advise you to take a look at Coq. Even though mainly used by Academics, it provides a logical framework and an interface to write formal and interactive proofs.
Based this language there exists some libraries dedicated to cryptographic proof :
...
12
It is always a bad idea to hash data that has a limited set of length or characters.
A phone number in Germany for example has normally no more than 12 digits.
The first digit is always a 0 and the vast majority of numbers is longer as 3 digits, as those are normally reserved for emergency services.
This effectively leaves us with 10^11-10^3 possible ...
12
In the general sense, The problem is known as the small input space on the hash functions, and in short simple hashing won't be secure.
If you hash data ( here a phone number) and an attacker tries to find an input value that matches the hash value is called the pre-image attack. In a secure Cryptographic hash functions pre-image attack requires $\mathcal{O}(...
11
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 ...
11
First up, I think your question is less something for crypto.SE and would fit better in the security.SE corner. Nevertheless, here goes:
...except his name or identity...
That's in itself already describes your problems when it comes to security and cryptography.
Problem due to lack of verification options.
Currently, world news outlets (example: ...
11
Two things going on that together may make plain-hash-then-encrypt insecure.
First, the distinction between secure MACs and hashes, which is that a hash function may allow you to derive $H(m')$ from $H(m)$ even if you only know how $m'$ and $m$ differ. Length extension attacks on SHA-1 and SHA-2 are a practical way that can happen, but there could be others ...
11
It is worth pointing out that Samy Kamkar realized and implemented (in 2015) what is now forehead-slappingly obvious in retrospect - it's perfectly practical to have a radio TX+RX unit that snoops a legitimate code and then turns on a momentary jammer transmitter to slightly corrupt the end of it (so it's not recognized as valid by the receiver). The keyfob ...
Only top voted, non community-wiki answers of a minimum length are eligible
