Open Stack

On 18 Nov 2016, at 8:14, Dean Troyer wrote:

>> -----Original Message-----
>> From: Luke Hinds <lhinds at redhat.com>
> [...]
>>> for non security related functions, but when it comes to government
>>> compliance and running OpenStack on public clouds (and even private for the
>>> Telcos / NFV), not meeting FIPS will in some cases block production getting
>>> a green light, or at least make it a big challenge to push through.
>
> Are there any know cases of this happening?  If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?
>
> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
>> Also, instead of creating bugs, I would suggest instead that we try to make this into a community goal. We would work with the TC and for P or Q, make it a goal to start migrating off of MD5 and have a goal for a cycle or two later to completely remove reliance on MD5.
>>
>> Doing this piecemeal via bugs will not be efficient and we'll need community buy-in.
>
> We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.

Swift does use md5 in two places: placement and integrity checking.

Placement:
MD5 is used in Swift's ring to balance the placement of data across the cluster. In pseudo code, we...

>>> h = hash(secret_prefix + name_of_thing + secret_suffix)
>>> lookup_index = h >> (32 - configurable_count)  # get the prefix bits
>>> list_of_drives = drive_table[lookup_index]  # get the drives this this is on

So what we're doing is using some bits at the beginning of the md5 output to splay the data across the system. Since md5 has even dispersion across the key space, this allows all the drives in the cluster to fill up evenly. This is key to Swift's availability, scaling, durability, and performance.

We've previously explored the idea of using some different algorithm for the ring hashing. We haven't for a few reasons, but primarily it's because md5 is "good enough" for our placement needs (fast enough, disperse enough) and is built in to the standard library. Also, because of the reason's below, we'll have to keep md5 around anyway, so there's been no big push to change this implementation and add a new dependency.


Integrity checking:
Swift uses md5 to detect bit flips and to do end-to-end integrity checking. We calculate and store the md5 of every object stored in swift and use that to detect if there are bit flips in the data. We have a background process that reads every bit of the object, computes the md5, and checks if that matches the stored md5. If not, the bad data is quarantined and durability is repaired from other data in the system. We also allow the end-user to send the expected md5 on an object write via the etag header. If the data written to disk doesn't match the supplied etag, the request fails. We also return the md5 of the data in the etag on object read responses and use the deterministic nature of the hash for conditional header requests (if-match, etc).

It's highly unlikely that we will ever be able to remove md5 from this part of the system, even if only for legacy purposes. Even if we had a new API version (which we've never done before) that used a different hash function, we'd still have to support the v1 API. We'd also have to deal with the EB of data already stored in Swift clusters today. They are all hashed with md5, and we'd still need to use it for auditing all of the existing data.

Any "changes" in a hash library in Swift would likely be additions, not a replacement.

That being said, from my reading the BLAKE2* family of hash algorithms looks very interesting.



--John






>
> dt
>
> -- 
>
> Dean Troyer
> dtroyer at gmail.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161118/fae37215/attachment.pgp>