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.
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
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
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
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
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
On Fri, Apr 23, 2010 at 3:57 AM, Paul Crowley p...@ciphergoth.org 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
On Thu, Apr 22, 2010 at 12:40 PM, Jonathan Katz jk...@cs.umd.edu 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 reduces security to a hard
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
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.
On Wed, Apr 21, 2010 at 8:49 PM, Jerry Leichter leich...@lrw.com 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
On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves sne...@dei.uc.pt 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
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
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,
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
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.
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 able to
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.
Unfortunately,
(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 only
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 it
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.
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
whether she
22 matches
Mail list logo
