New answers tagged

3

I'll answer question 2, leaving the first as an exercise to the reader. I'll do this on intuitive grounds, rather than using explicit conditional probabilities. The adversary is free to compute $v_1\cdot v_2$ regardless of what we ask, therefore removing everything about that and $v_3$ does not change the problem, which reduces to: We somewhat have ...


6

No, TLS is not secure against VM reset attacks. There are at least two attacks that are made possible by VM reset attacks, off the top of my head: AES-GCM nonces are typically generated deterministically from the message counter value. If you set the snap shot prior to the local peer sending a plain text message that will change after resetting to the snap ...


0

If you break this down in terms of a client/server relationship I think it may offer some insight. TLS is neither explicitly or implicitly vulnerable and, like you said, it depends on the implementation. For example: if the server utilizing TLS is virtualized, then rolling back to that point may introduce a replay. But if you’re talking about client ...


0

OTR is trying to achieve the same unbreakability of OTPs by changing keys. The unbreakable part of OTPs comes from the following: Consider if the one-time pad is used to encode the word "otter." If an attacker tries to brute force the contents of the pad, the message will "decrypt" into every possible combination of 6 characters (e.g.: "lemur." "badger" ...


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


1

well simply said true, with more key changes she can bruteforce the same keys over more messages which may give her faster results but when one key actually has hit, it is just valid for one part of the message and not everything. Essentially a one-time-pad uses a different key for every message which is the whole point of it. because key re-usage makes the ...


1

This is an example of an attack in a multi-key setting. Since the objective is that all communications remain secret, rekeying does reduce the effective security. In the case of only a thousand keys this is not very severe, since it only amounts to about a 10-bit loss: 118-bit security is still large enough by a clear margin. However, if you had a million ...


4

OTR uses 128 bit AES-CTR. There is a risk that the same AES key will be generated more than once, but if significantly less than $2^{32}$ messages are ever exchanged between any pair of peers, this risk might be safely considered to be negligible. However, if a pair of peers exchange more messages than $2^{32}$ and depending on how the implementation ...


5

Strictly speaking, it does make a brute-force attack more likely to recover a key for any message pair, but the impact of recovering a single key is minimized by frequent re-keying, since that key can't aid the adversary in decrypting any other messages. If you don't re-key, a brute force attack is only marginally more difficult but success gives you ...



Top 50 recent answers are included