meta user
network profile
| bio | website | google.com |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 6 months |
| seen | 55 mins ago | |
| stats | profile views | 23 |
|
10h |
revised |
Why this k parameter is in unary in adversary PPT algorithm? fixed my misreading of OP |
|
10h |
comment |
Why this k parameter is in unary in adversary PPT algorithm? Incidentally, this would probably fit better on cstheory. $\:$ |
|
10h |
answered | Why this k parameter is in unary in adversary PPT algorithm? |
|
1d |
comment |
Alternatives to HMAC + CBC? I imagine things would be easier if you moved the HMAC to the end. $\:$ |
|
1d |
comment |
Is this a sensible cryptographic protocol intending to reduce the impact of compromised security? ... so, your nodes are going to need to read more of that data than they $\hspace{1.96 in}$ have the ability to decrypt with AES? $\:$ |
|
May 15 |
comment |
Encrypting a broadcast channel I suppose I would suggest that the subscriber decrypts their section with their personal key to get "comkey", decrypts another pair of sections with "comkey" to get the session key and a decommitment to it, verifies the decommitment (against the commitment included in the broadcast stream), and then decrypts the whole message with the session key. $\:$ There are "verifiable broadcast encryption schemes" which also rule out [some but not all receivers get a decryption error], but I imagine those would be much less efficient. $\;\;$ |
|
May 14 |
comment |
Encrypting a broadcast channel Note that the method given in this answer does not offer the receivers any $\hspace{1.43 in}$ assurance that they won't get different messages. $\:$ |
|
May 14 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? You have a good point there. $\:$ |
|
May 14 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? @Joshua: $\:$ How should Bob verify the key he gets? $\;\;\;$ |
|
May 14 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? That approach would let an adversary, with a correspondingly small probability, compute the honest $\;\;$ party's secret an arbitrary factor faster than the honest party can compute the adversary's secret. |
|
May 13 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? No, I mean hiding the key with a time-lock puzzle. $\:$ |
|
May 13 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? I suppose the assumption/constraint needed for the latter property is that $\hspace{1.33 in}$ computation is not much easier for the adversary. $\:$ |
|
May 13 |
comment |
Is there a way to do fair exchange between two parties who don't trust each other? I think that "designated aborter" (as you described) and "an aborter can't learn the honest party's $\;\;$ message with much less effort than the honest party can learn the aborter's message" are the two optimal properties for the setting without a third party (and that a protocol in that setting can't have both of those). $\:$ |
|
May 11 |
comment |
Does SRP reduce to DH key echange when shared password is not secret? In fact, how do you show that "as long as you get the same session key, everything is fine", $\hspace{.81 in}$ for either DH or public-password SRP? $\:$ (Getting the same session key for a generic secure key $\;\;$ agreement protocol is not sufficient to conclude that everything is fine.) $\;\;\;$ |
|
May 11 |
comment |
Does SRP reduce to DH key echange when shared password is not secret? It seems somehow risky, since we must avoid revealing useful information about $K$. $\hspace{.61 in}$ |
|
May 11 |
comment |
Does SRP reduce to DH key echange when shared password is not secret? The length of what one should read/compare would not depend on what that was derived from. |
|
May 11 |
comment |
Does SRP reduce to DH key echange when shared password is not secret? Verifying "some value derived from the negotiated secret $K$" seems unnecessarily complicated, when one could instead verify some value derived from the transcript of the negotiation. $\:$ |
|
May 10 |
reviewed | Reviewed Does SRP reduce to DH key echange when shared password is not secret? |
|
May 10 |
reviewed | Reviewed Now that quantum computers have been out for a while, has RSA been cracked? |
|
May 10 |
reviewed | Close random number generator 10-side dice alternative |
