couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Why MD5 is used for hashes, also about non-deterministic IDs.
Date Sun, 20 Nov 2011 17:55:19 GMT
On Sun, Nov 20, 2011 at 1:54 AM, Alex Besogonov
<alex.besogonov@gmail.com> wrote:
> On Thu, Nov 17, 2011 at 5:57 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> On Wed, Nov 16, 2011 at 09:46, Alex Besogonov <alex.besogonov@gmail.com> wrote:
>>> On Tue, Nov 15, 2011 at 4:23 PM, Randall Leeds <randall.leeds@gmail.com>
wrote:
> [skip]
>> I hope that settles the "why", reassures any
>> "oh-my-god-my-couch-is-vulnerable", and motivates the
>> "hey-lets-make-a-patch" if you still want the feature, with the
>> understanding that it's unlikely the project will specify this as a
>> necessary condition for general-purpose replication. If you have more
>> bullet-proof needs, dev that armor up and I'll review it, but I'd
>> advise making it a config option.
> Well, I'm currently trying to replicate Couch DB behavior exactly, but
> I'm slowly moving
> towards 'hey, I'll just write a patch' stage. However, I like an idea
> of waiting for SHA-3
> competition to finish since it give me more time :)
>

Just a note, but remember that you should be able to use sha-8billion
in your replicator and it'd work fine with CouchDB (and if it doesn't,
its a bug in CouchDB that we'd want to fix). The replicator/revision
mechanism is written so that once generated, the _rev tokens are
opaque and the only tests used are equality comparisons.

HTH,
Paul Davis

>>>
>>>> Then, if I understand Jason
>>>> correctly, we're also talking about a situation where Couch B is
>>>> insecure... it's allowing a malicious user to change documents. If
>>>> these documents are anything more important than something affecting
>>>> the user herself then what you have is a malicious administrator or an
>>>> insecure deployment. I don't think MD5 is to blame here.
>>> No, the issue here is a possibility to break the synchronization.
>>>
>>>> Does that sound like a reasonable assessment to you, Alex?
>>> Almost.
>>>
>>>> Also, I'd love to hear about your C++ replicator as it develops.
>>> Sure, I'm developing a very small and fast embedded storage for mobile
>>> devices and desktop apps. It'll be open source once I finish its core.
>>>
>>>> -Randall
>>>>
>>>>> For switching from MD5 to SHA-1, I say no. If we switch, let's use
>>>>> something contemporary like SHA-256. Better yet, let's wait for the
>>>>> winner of the SHA-3 competition.
>>>>>
>>>>> B.
>>>>>
>>>>> On 15 November 2011 07:57, Jason Smith <jhs@iriscouch.com> wrote:
>>>>>> On Tue, Nov 15, 2011 at 7:34 AM, Alex Besogonov
>>>>>> <alex.besogonov@gmail.com> wrote:
>>>>>>>>> Now I make a change to 'Doc' at machine A. This creates
a new revid
>>>>>>>>> with new md5 hash.
>>>>>>>>> A malicious software somehow learns about this update
and creates
>>>>>>>>> another document
>>>>>>>>> on machine B, contriving it so to make the resulting
hash to be the
>>>>>>>>> same as on machine A.
>>>>>>>> Before going any further, you must show why we care about
the contents
>>>>>>>> of machine B.
>>>>>>>> Why would I log in to machine B if I do not trust B's owner?
Why would
>>>>>>>> I clone your Git repository if I do not know you?
>>>>>>> The problem is, MD5 hash depends on _untrusted_ data that external
>>>>>>> processes might put into the database.
>>>>>>>
>>>>>>> For example, imagine that machines A and B use CouchDB to store
>>>>>>> certificates.
>>>>>>
>>>>>> I ask again.
>>>>>>
>>>>>> --
>>>>>> Iris Couch
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message