couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Besogonov <alex.besogo...@gmail.com>
Subject Re: Why MD5 is used for hashes, also about non-deterministic IDs.
Date Sun, 20 Nov 2011 07:54:58 GMT
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 :)

>>
>>> 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