On Wednesday,2009-11-04, at 7:04 , Darren J Moffat wrote:
The SHA-256 is unkeyed so there would be nothing to stop an
attacker that can write to the disks but doesn't know the key from
modifying the on disk ciphertext and all the SHA-256 hashes up to
the top of the Merkle tree to the
Folks:
We're going to be deploying a new crypto scheme in Tahoe-LAFS next
year -- the year 2010. Tahoe-LAFS is used for long-term storage, and
I won't be surprised if people store files on Tahoe-LAFS in 2010 and
then rely on the confidentiality and integrity of those files for
many
Dear Darren J Moffat:
I don't understand why you need a MAC when you already have the hash
of the ciphertext. Does it have something to do with the fact that
the checksum is non-cryptographic by default (http://docs.sun.com/app/
docs/doc/819-5461/ftyue?a=view ), and is that still true?
On 2009 Oct 19, at 9:15 , Jack Lloyd wrote:
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
DSA was (designed to be) full of covert channels.
one can make DSA deterministic by choosing the k values to be HMAC-
SHA256(key, H(m))
I've noticed people tinkering with (EC) DSA by
On Wednesday,2009-09-16, at 14:44 , Ivan Krstić wrote:
Yes, and I'd be happy to opine on that as soon as someone told me
what those important problems are.
The message that you quoted from Brian Warner, which ended with him
wondering aloud what new applications could be enabled by such
following-up to my own post:
On Monday,2009-09-14, at 10:22 , Zooko Wilcox-O'Hearn wrote:
David-Sarah Hopwood suggested the improvement that the integrity-
check value V could be computed as an integrity check (i.e. a
secure hash) on the K1_enc in addition to the file contents.
Oops
And while you are at it, please implement these test vectors and
report to Niels Ferguson:
http://blogs.msdn.com/si_team/archive/2006/05/19/aes-test-vectors.aspx
Regards,
Zooko
-
The Cryptography Mailing List
Unsubscribe by
[added Cc: tahoe-...@allmydata.org, and I added ke...@guarana.org on
the whitelist so his posts will go through to tahoe-dev even if he
isn't subscribed]
On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote:
Possession of the read-cap to the mutable file gives you two
things: it gives you
On Thursday,2009-08-27, at 19:14 , James A. Donald wrote:
Zooko Wilcox-O'Hearn wrote:
Right, and if we add algorithm agility then this attack is
possible even if both SHA-2 and SHA-3 are perfectly secure!
Consider this variation of the scenario: Alice generates a
filecap and gives
So How Do You Manage Your Keys Then, part 3 of 5
In part one of this series [1] I described how Tahoe-LAFS combines
decryption, integrity-checking, identification, and access into one
bitstring, called an immutable file read-cap (short for
capability). In part two [2] I described how
Folks:
My brother Nathan Wilcox asked me in private mail about protocol
versioning issues. (He was inspired by this thread on
cryptography@metzdowd.com [1, 2, 3]). After rambling for a while
about my theories and experiences with such things, I remembered this
vexing
Okay, in today's installment I'll reply to my friend Kris Nuttycombe,
who read yesterday's installment and then asked how the storage
service provider could provide access to the files without being able
to see their filehandles and thus decrypt them.
I replied that the handle could be
On Wednesday,2009-08-19, at 10:05 , Jack Lloyd wrote:
On Wed, Aug 19, 2009 at 09:28:45AM -0600, Zooko Wilcox-O'Hearn wrote:
[*] Linus Torvalds got the idea of a Cryptographic Hash Function
Directed Acyclic Graph structure from an earlier distributed
revision control tool named Monotone
[removing Cc: tahoe-dev as this subthread is not about Tahoe-LAFS.
Of course, the subscribers to tahoe-dev would probably be interested
in this subthread, but that just goes to show that they ought to
subscribe to cryptogra...@metzdowd.com.]
On Monday,2009-08-10, at 11:56 , Jason Resch
This conversation has bifurcated, since I replied and removed tahoe-
dev from the Cc: line, sending just to the cryptography list, and
David-Sarah Hopwood has replied and removed cryptography, leaving
just the tahoe-dev list.
Here is the root of the thread on the cryptography mailing list
On Monday,2009-08-10, at 13:47 , Zooko Wilcox-O'Hearn wrote:
This conversation has bifurcated,
Oh, and while I don't mind if people want to talk about this on the
tahoe-dev list, it doesn't have that much to do with tahoe-lafs
anymore, now that we're done comparing Tahoe-LAFS
[dropping tahoe-dev from Cc:]
On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote:
Zooko Wilcox-O'Hearn wrote:
I don't think there is any basis to the claims that Cleversafe
makes that their erasure-coding (Information Dispersal)-based
system is fundamentally safer
...
Surely
[dropped tahoe-dev from Cc:]
On Thursday,2009-08-06, at 17:08 , james hughes wrote:
Until you reach the threshold, you do not have the information to
attack. It becomes information theoretic secure.
This is true for information-theoretically secure secret sharing, but
not true for
modern cryptosystems and in many cases would not
be necessary either.
Okay I think that's it. I hope these notes are not so terse as to be
confusing or inflammatory.
Regards,
Zooko Wilcox-O'Hearn
[1] http://allmydata.org/pipermail/tahoe-dev/2009-July/002482.html
[2] http://allmydata.org
Poly1305 to VMAC, please report
your measurement, at least to me privately if not to the list. I can
use that sort of feedback to contribute improvements to the Crypto++
library. Thanks!
Regards,
Zooko Wilcox-O'Hearn
---
Tahoe, the Least-Authority Filesystem -- http://allmydata.org
store
as a
labor of love by volunteers; developer time is no longer funded by
allmydata.com (see [13] for details).
Zooko Wilcox-O'Hearn
on behalf of the Tahoe-LAFS team
Special acknowledgment goes to Brian Warner, whose superb engineering
skills and dedication are primarily responsible for the Tahoe
Folks:
Over on the Tahoe-LAFS mailing list Brian Warner gave a typically
thoughtful, thorough, and precise analysis of cleversafe access
control as contrasted with Tahoe-LAFS access control. Brian
attempted to cross-post it to this list, but it bounced since he is
not a subscriber.
[cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com]
Disclosure: Cleversafe is to some degree a competitor of my Tahoe-
LAFS project. On the other hand, I tend to feel positive towards
them because they open-source much of their work. Our Related
Projects page has
On Sunday,2009-07-19, at 13:24 , Paul Hoffman wrote:
At 7:54 AM -0600 7/18/09, Zooko Wilcox-O'Hearn wrote:
This involves deciding whether a 192-bit elliptic curve public key
is strong enough...
Why not just go with 256-bit EC (128-bit symmetric strength)? Is
the 8 bytes per signature
By the way, we've recently been planning our next crypto-capabilities
design for the TahoeLAFS secure distributed filesystem. This
involves deciding whether a 192-bit elliptic curve public key is
strong enough, as well as subtler and more unusual issues involving
embedding keys directly
(in addition to RSA and ECDSA
for backward compatibility).
Regards,
Zooko Wilcox-O'Hearn
P.S. Oh, I told a lie in the interests of brevity when I said that
file handles contain actual public keys or actual private keys. RSA
keys are way too big for that. So instead we go through interesting
For what it is worth, in the Tahoe-LAFS project [1] we simply use CTR
mode and a unique key for each file. Details: [2]
Tahoe-LAFS itself doesn't do any deltas, compression, etc., but there
are two projects layered atop Tahoe to add such features -- a plugin
for duplicity [3] and a new
27 matches
Mail list logo
