meta user
network profile
| bio | website | google.com |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 7 months |
| seen | 5 hours ago | |
| stats | profile views | 23 |
|
9h |
revised |
sir,please suggest me an algorithm or method how can i improve the prediction based encryption method using randomization? imporoved spacing, capitalization, and grammar |
|
9h |
suggested | suggested edit on sir,please suggest me an algorithm or method how can i improve the prediction based encryption method using randomization? |
|
1d |
comment |
Proper Way to Encrypt Data with Two Keys? symmetric or asymmetric? $\;$ |
|
1d |
comment |
Requiring a “supervisor” key pair and a “user” key pair to decrypt multiple-recipient messages No, he said he wants Jim to be able to supervise (not designate) who can decrypt, $\hspace{1.4 in}$ without being able to decrypt himself. $\:$ The sensible interpretation of this is that Jim controls $\hspace{1 in}$ who among the people selected by Bob can decrypt. $\;\;$ |
|
May 21 |
comment |
Do I need to keep a 64-bit version number secret? If the receiver already knows version, then you can use version as the associated data in SIV mode. |
|
May 18 |
revised |
Why this k parameter is in unary in adversary PPT algorithm? fixed my misreading of OP |
|
May 18 |
comment |
Why this k parameter is in unary in adversary PPT algorithm? Incidentally, this would probably fit better on cstheory. $\:$ |
|
May 18 |
answered | Why this k parameter is in unary in adversary PPT algorithm? |
|
May 18 |
comment |
Alternatives to HMAC + CBC? I imagine things would be easier if you moved the HMAC to the end. $\:$ |
|
May 17 |
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}$ |
