remote file interface for waterken, friday meeting topic

[Marc Stiegler]

--marcs

[David Wagner]

Regarding FileRem.java:

I recommend using SHA256 instead of MD5. MD5 has serious security
problems, so should not be used. And for future-proofing, SHA256,
seems better than SHA1. (Once you fix the hash algorithm, it won't
be easy to change it in the future without breaking other apps.)

[Stiegler, Marc D]

Will do. Thank you.

--marcs

> --
> You received this message because you are subscribed to the
> Google Groups "friam" group.
> To post to this group, send email to fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> friam+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/friam?hl=en.
>
>

[Kevin Reid]

I also recommend not using the generic name "getHash()", but either
including the name of the hash algorithm in the name, or including a
parameter naming a hash algorithm. The former is basic future-
confusion-proofing and warns the programmer about what they should
expect; the latter has the advantage that if there's anywhere else in
your system that has a 'getHash()' you can expand the algorithm
support uniformly without adding methods everywhere.

Since E faces the same issue: Does anyone know of a reliable namespace
for hash algorithms? We speak of "MD5" and "SHA-1" and "SHA256" and so
on, but is there something that's formally specified so as to avoid
inventing our own naming scheme but not risk collisions or multiple
names too much?

--
Kevin Reid <http://switchb.org/kpreid/>

[Bill Frantz]

I would think one could specify the interface so the hash algorithm can
be changed every time the hash value changes. That should be often
enough for most cases.

However, it is a good idea to start with a hash that doesn't have known
problems.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz |"After all, if the conventional wisdom was working, the
408-356-8506 | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum

[Stiegler, Marc D]

The bigger problem is that we stand on the slippery slope of, "eeek, what happens in the case where there are several versions of the server in the world, and different ones are using different hashes?" I'll give this some thought.

--marcs

> -----Original Message-----
> From: fr...@googlegroups.com [mailto:fr...@googlegroups.com]
> On Behalf Of Bill Frantz
> Sent: Friday, April 02, 2010 3:11 PM
> To: fr...@googlegroups.com
> Subject: Re: [friam] remote file interface for waterken,
> friday meeting topic
>

[Bill Frantz]

On 4/2/10 at 3:13 PM, marc.d....@hp.com (Stiegler, Marc D) wrote:

>The bigger problem is that we stand on the slippery slope of,
>"eeek, what happens in the case where there are several
>versions of the server in the world, and different ones are
>using different hashes?" I'll give this some thought.

My thought was to say that a hash value is only valid in
relation to a
particular FileRem.java interface instance. Two programs
accessing a
file through different instances might see different
values/lengths for
the hash value. When changing the hash algorithm, an instance
only needs
to ensure that it generates different values than the older algorithm(s)
generated. Given the probabilistic nature of hashes, I think
that there
is sufficient assurance in their semi-"random" nature, but an algorithm
ID in the returned string would make this assurance a certainty.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | gets() remains as a monument | Periwinkle
(408)356-8506 | to C's continuing support of | 16345
Englewood Ave
www.pwpconsult.com | buffer overruns. | Los Gatos,
CA 95032

[David Wagner]

> The bigger problem is that we stand on the slippery slope of, "eeek, what happens in the case where there are several versions of the server in the world, and different ones are using different hashes?" I'll give this some thought.

Indeed. I'm not convinced that the complexity of supporting multiple
hashes is worth it. What's the expected lifetime of a hash function?
10-20 years or so? That's not too shabby, by software standards. :-) I
don't even want to think about a system where some elements support one
hash and another support another hash. The further I would be inclined
to go towards algorithm agility would be to consider possibly naming
the method getSHA256() instead of getHash(), to leave yourself a degree
of freedom for the future to introduce a getSHA512() [or whatever] and
deprecate the prior method, if necessary. But that's a bridge you can
cross when you come to it. For now, SHA256 looks like it has plenty of
life in it, and I wouldn't worry about doing anything more to support
other algorithms. I wouldn't bother with a configurable system for
choosing hashes, or anything like that.

Keep in mind that it's really easy to focus on the cryptography and
obsess over the details of how to maximize the strength (should we use a
2048-bit key or a 4096-bit key? PKCS, OAEP, or OAEP+ padding?), but when
using modern cryptographic algorithms in a reasonable way, the crypto
is almost never the weakest link in the system. I say this as a former
cryptographer and one who still enjoys obsessing over those details. :-)

[Norman Hardy]

I suspect that conventional shared file systems could be augmented to always know the hash of a file.
This addition would help many applications including the seldom provided http hash query.
Standing where the file system stands you can do lazy hash calculation.
To be efficient you need a Merkle tree hash which technically excludes either SHA1 or SHA256.

Keykos could have provided files with these properties outside the kernel. We didn't.
Such magic was not easily composed with other file magic such as virtual mutable copies.

[Zooko O'Whielacronx]

On Fri, Apr 2, 2010 at 2:59 PM, Kevin Reid <kpr...@mac.com> wrote:
>
> Since E faces the same issue: Does anyone know of a reliable namespace for
> hash algorithms? We speak of "MD5" and "SHA-1" and "SHA256" and so on, but
> is there something that's formally specified so as to avoid inventing our
> own naming scheme but not risk collisions or multiple names too much?

http://www.users.zetnet.co.uk/hopwood/crypto/scan/

By David-Sarah Hopwood!

Regards,

Zooko

[Kevin Reid]

The apparent update date is 2002. Is it being kept up to date? I don't
know how fast crypto algorithms appear.

[David-Sarah Hopwood]

Note that this hasn't been updated for almost 8 years. (In fact I haven't
paid that internet service provider for years, so I'm not sure why the
web site is still there.)

Wikipedia has pretty good coverage of cryptographic primitives, and unlike
SCAN, it has many references to cryptanalysis since 2002. I have no plans
to update SCAN; I should really take the site down.

--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

[Zooko O'Whielacronx]

On Sat, Apr 3, 2010 at 6:44 PM, David-Sarah Hopwood
<david...@jacaranda.org> wrote:
> Note that this hasn't been updated for almost 8 years. (In fact I haven't
> paid that internet service provider for years, so I'm not sure why the
> web site is still there.)
>
> Wikipedia has pretty good coverage of cryptographic primitives, and unlike
> SCAN, it has many references to cryptanalysis since 2002. I have no plans
> to update SCAN; I should really take the site down.

Ah, but for better or for worse there is no other catalog of crypto
algorithms with precise names defined. Wei Dai seems to have a
"mirror" of SCAN. For example:

http://cryptopp.com/docs/ref/sha_8h-source.html

Has this at the top of the file:

00008 /// <a href="http://www.weidai.com/scan-mirror/md.html#SHA-1">SHA-1</a>
00009 class CRYPTOPP_DLL SHA1 : public
IteratedHashWithStaticTransform<word32, BigEndian, 64, 20, SHA1>

I don't know if Wei Dai has been updating his "mirror" of SCAN, but I
wouldn't be surprised since he has implemented many newer algorithms
in Crypto++.

There is also cryptolounge.org:
http://www.cryptolounge.org/wiki/Category:Algorithm

But it doesn't have precise names defined and it doesn't seem to be
very comprehensive.

Regards,

Zooko