On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves wrote
(on the cryptogra...@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
On Sun, Jul 11, 2010 at 4:50 AM, Francois Grieu wrote:
>
> [I suddenly got a batch of old messages, and wonder what is the
> appropriate list address]
cryptogra...@metzdowd.com is the venerable [*] standby which is
manually moderated by Perry Metzger. Every post to
cryptogra...@metzdowd.com await
On Mon, Sep 13, 2010 at 11:01 AM, mhey...@gmail.com wrote:
>
> The 50,000 ft view is that IPsec HMAC-SHA1
> costs about the same amount of processing as TCP.
...
> Even with the heaviest
> authentication (HMAC-SHA1) the video was completely intelligible with
> only the occasional stutter.
Also, e
following-up to my own post:
On Tue, Sep 14, 2010 at 8:54 AM, Zooko O'Whielacronx wrote:
>
> Also, even if you did have a setting where the CPU cost of HMAC-SHA1
> was a significant part of your performance (at e.g. 12 cycles per byte
> [1]), then you could always switch to Pol
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
[adding Cc: tahoe-...@tahoe-lafs.org to a thread originated on
cryptography@randombit.net:
http://lists.randombit.net/pipermail/cryptography/2010-October/000189.html
]
On Tue, Oct 5, 2010 at 1:04 PM,
wrote:
> I don't know if anyone else noticed this but...
I think it is mentioned briefly in "Cry
http://tahoe-lafs.org/pipermail/tahoe-dev/2010-October/005353.html
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
Dear cryptography@randombit.net:
I just sent this letter to a mailing list of SHA-3 designers. I
thought you might be interested in the general question.
Regards,
Zooko
Folks:
If a hash has 32-bit pre-image-resistance then this means an attacker
might spend about 2^32 resources to find a pre-i
Following-up to my own post to correct a goof:
On Wed, Oct 13, 2010 at 10:56 PM, Zooko O'Whielacronx wrote:
>
> If a hash has 32-bit pre-image-resistance then this means an attacker
> might spend about 2^32 resources to find a pre-image.
>
> If a hash has 64-bit pre-image-
Oh, and now I need to follow-up to my follow-up to correct an
over-simplification.
On Thu, Oct 14, 2010 at 8:33 PM, Zooko O'Whielacronx wrote:
> I know that collision resistance
> is approximately as difficult to achieve as the square of pre-image
> resistance is.
Actually the
I like the way you think.
On Thu, Oct 14, 2010 at 12:32 PM, Marsh Ray wrote:
>>
>> What if a hash has 512-bit collision-resistance? What would that mean?
>> That an attacker might spend about 2^512 resources to find a collision
>> in it?
>
> The attacker can match any hash he generates with any o
I don't know what we're going to do if we are threatened with legal
penalties for failing to insert backdoors into Tahoe-LAFS, but I know
what we're not going to do.
Regards,
Zooko Wilcox-O'Hearn
___
cryptography mailing list
cryptography@randombit.net
On Thu, Dec 16, 2010 at 6:41 PM, Paul Hoffman wrote:
> At 7:06 PM -0600 12/16/10, Marsh Ray wrote:
>>There were some wild accusations made and widely repeated, I'm trying my best
>>to stick to facts and not direct accusations about anyone.
>
> You failed (miserably, in my opinion).
It is underst
ANNOUNCING Tahoe, the Least-Authority File System, v1.8.2
The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.8.2 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:
http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html
Tahoe-LAFS
Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
http://cr.yp.to/ecdh/patents.html
The section on "Point Compression" says:
"""
Miller in 1986, in the paper that introduced elliptic-curve
cryptography, suggested compressing a public key (x,y) to simply x:
``Finally, it sho
On Fri, May 20, 2011 at 3:30 PM,
wrote:
>
> I wonder if A/V shouldn't use something similar?
What's A/V?
> I assume MD4 is an outdated choice - perhaps some cryppie needs to
> design a hash function that is specifically designed for a FIFO kind
> of window? Maybe there is and I'm just out of th
Dear Paul Crowley:
How about the "Compact Representation", section 4.2, of RFC 6090:
http://www.rfc-editor.org/rfc/rfc6090.txt
Is that the same "point compression" that you were looking for?
Regards,
Zooko
___
cryptography mailing list
cryptography@r
Dear Nico Williams:
Thanks for the reference! Very cool.
What I would most want is for ZFS (and every other filesystem) to
maintain a Merkle Tree over the file data with a good secure hash.
Whenever a change to a file is made, the filesystem can update the
Merkle Tree this with mere O(log(N)) wor
Daniel J. Bernstein wrote to me on 2011-05-14. Everything below is
quoted from that letter. --Zooko
--- begin appended copy of letter
Hi Zooko,
I tried following up to cryptography@randombit.net but haven't taken the
time to figure out which hoops to jump through to make messages actually
app
Also related, Eric Hughes posted about something he called "Encrypted
Open Books" on 1993-08-16. The idea was to allow an auditor to confirm
the correctness of the accounts without being able to see the details
of people's accounts.
Regards,
Zooko
___
c
On Tue, Jul 12, 2011 at 11:10 AM, Hill, Brad wrote:
>
> I have found that when H3 meets deployment and use, the reality too often
> becomes: "Something's gotta give." We haven't yet found a way to hide enough
> of the complexity of security to make it free, and this inevitably causes
> conflic
On Tue, Jul 12, 2011 at 5:25 PM, Marsh Ray wrote:
>
> Everyone here knows about the inherent security-functionality tradeoff. I
> think it's such a law of nature that any control must present at least some
> cost to the legitimate user in order to provide any effective security.
> However, we c
announcing Tahoe-LAFS v1.8.3, fixing a security issue
Dear People of the cryptography@randombit.net mailing list:
We found a vulnerability in Tahoe-LAFS (all versions from v1.3.0 to v1.8.2
inclusive) that might allow an attacker to delete files. This vulnerability
does not enable anyone to read f
Hello John Tromp!
That is neat! The paper could use a related work section, for example
Litecoin uses scrypt in the attempt to make it harder to implement in
ASIC:
https://litecoin.info/Scrypt
The current Password Hashing Contest (disclosure: I am on the panel)
may be relevant to your interests:
32 matches
Mail list logo
