Bear wrote:
>
> DH is an "open" protocol; it doesn't rely on an initial shared
> secret or a Trusted Authority.
>
> There is a simple proof that an open protocol between anonymous
> parties is _always_ vulnerable to MITM.
>
> Put simply, in an anonymous protocol, Alice has no way of knowing
> w
Bear wrote:
>
> If it's an anonymous protocol, then "credit" for being a good chess
> player is a misnomer at best; the channel cannot provide credit to
> any particular person.
I understand the objection, which is why I made the notion concrete by saying
that Mitch wins if he gets the first pl
It's clear that my challenge about the Chess Grandmaster Problem has thrown
more shadow than light.
This is partly because it is an inherently tricky problem, but also because
I confused the issue by talking about both traditional Chess Grandmaster (a
problem that I am interested in) and Full-
> Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85,
> which are on my shelf. Where was it published?
R. L. Rivest and A. Shamir. How to expose an eavesdropper. Communications of the ACM,
27:393-395, April 1984.
I can think of three different goals one could have for "identifying" the
person behind a name. If goal A is possible, I say that the name was a
"verinym". If goal C is possible, I say that the name was a pseudonym. If
none of the goals are possible, the transaction was anonymous.
Unfortunatel
(about the Interlock Protocol)
Benja wrote:
>
> The basic idea is that Alice sends *half* of her ciphertext, then Bob
> *half* of his, then Alice sends the other half and Bob sends the other
> half (each step is started only after the previous one was completed).
> The point is that having on
Ed Gerck wrote:
>
> It's possible to have at least one open and anonymous protocol
> immune to MITM -- which I called multi-channel DH.
This is a good idea!
I used to advocate it on the cypherpunks list (e.g. [1]).
Later I learned that it is called a "Merkle Channel". From _MOV_ [2], page 48:
Rich Salz wrote:
>
> You know about Wei's Crypto++, right?
I use it and like it. I don't have to dig into the guts very often, which is
good because I don't like mucking around in C++.
You have to understand templates to understand the API. The docs are spartan,
but the design is clean so i
Jill Ramonsky <[EMAIL PROTECTED]> wrote:
>
> I confess ignorance in matters concerning licensing. The basic rules
> which I want, and which I believe are appropriate are:
> (i) Anyone can use it, royalty free. Even commercial applications.
> (ii) Anyone can get the source code, and should be abl
On 2004, Sep 11, , at 17:20, Sandy Harris wrote:
Zooko O'Whielcronx wrote:
I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN
this is called "opportunistic encryption".
That is certainly not what FreeS/WAN meant by "opportunistic
encryption".
http://www.freeswan.org/freeswan_tree
Something that is interesting about this issue is that it involves
transitive vulnerability.
If there are only two actors there is no issue. If Alice is the user
and Bob is the software maintainer and Bob is bad, then Alice will be
exploited regardless of the hash function. If Alice is the us
I would love to have an information-theoretic argument for the security
of my PRNG, but that's not what we have, and I don't think reducing the
entropy_count by one bit per output bit gets us any closer to such an
argument.
For starters, the entropy_count value before you output the bit is
obv
Hal:
Thanks for the news about the planned NIST-sponsored hash function
competition. I'm glad to hear that it is in the works.
Yesterday I profiled my on-line data backup application [1] and
discovered that for certain operations one third of the time is spent in
SHA-1. For that reason, I'
I like the ideas, John.
The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer the "higher"
or "outer" layer a way to hook into the crypto from your inner layer.
On Jan 26, 2009, at 13:08 PM, John Levine wrote:
> If only. People have been saying for at least a decade that all we
> have to do to solve the spam problem is to charge a small fee for
> every message sent.
I was one of those people, a decade and a half ago, on the cypherpunks
mailing list. In
On Wed, Apr 21, 2010 at 8:49 PM, Jerry Leichter wrote:
> There are some concrete complexity results - the kind of stuff Rogoway does,
> for example - but the ones I've seen tend to be in the block
> cipher/cryptographic hash function spaces. Does anyone one know of similar
> kinds of results for
On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves wrote
(on the cryptography@metzdowd.com list):
> [2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf
I've been looking at that one, with an eye to using it in the One
Hundred Year Cryptography project that is being sponsored by Google as
part of
By the way, the general idea of One Hundred Year Security as far as
digital signatures go would be to combine digital signature
algorithms. Take one algorithm which is bog standard, such as ECDSA
over NIST secp256r1 and another which has strong security properties
and which is very different from E
On Fri, Apr 23, 2010 at 3:57 AM, Paul Crowley wrote:
>
> My preferred signature scheme is the second, DDH-based one in the linked
> paper, since it produces shorter signatures - are there any proposals which
> improve on that?
http://eprint.iacr.org/2007/019
Has one. Caveat lector.
Regards,
Zo
On Thu, Apr 22, 2010 at 12:40 PM, Jonathan Katz wrote:
> On Thu, 22 Apr 2010, Zooko O'Whielacronx wrote:
>
>> Unless I misunderstand, if you read someone's plaintext without having
>> the private key then you have proven that P=NP!
…
> The paper you cite reduce
Folks:
Regarding earlier discussion on these lists about "the difficulty of
factoring" and "post-quantum cryptography" and so on, you might be
interested in this note that I just posted to the tahoe-dev list:
"100-year digital signatures"
http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/00443
Dear people of the cryptography mailing lists:
We just released Tahoe-LAFS v1.7. The major new feature is an SFTP
server. This means that (with enough installing software and tinkering
with your operating system configuration) you can have a
normal-looking mount point backed by a Tahoe-LAFS grid.
Dan:
You didn't mention the option of switching to elliptic curves. A
256-bit elliptic curve is probably stronger than 2048-bit RSA [1]
while also being more efficient in every way except for CPU cost for
verifying signatures or encrypting [2].
I like the Brainpool curves which comes with a bette
ANNOUNCING Tahoe, the Least-Authority File System, v1.7.1
The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.7.1 of Tahoe-LAFS, an extremely
reliable distributed storage system.
Tahoe-LAFS is the first distributed storage system which
offers "provider-independent s
On Wed, Sep 1, 2010 at 2:55 PM, Ben Laurie wrote:
>>
>> Therefore, you would end up hashing your messages with a
>> secure hash function to generate "message representatives" short
>> enough to sign.
> Way behind the curve here, but this argument seems incorrect. Merkle
> signatures rely on the p
ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0
The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.8.0 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:
http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html
Tahoe-LAFS
http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/backdoors.txt
Statement on Backdoors
October 5, 2010
The New York Times has recently reported that the current U.S.
administration is proposing a bill that would apparently, if passed,
require communication systems to facilitate government
27 matches
Mail list logo
