关于 Hashable

翻译来源
Swift 4.2 improves Hashable with a new Hasher struct

Swift 4.2对 Hashable 协议做了优化,使其 更快、更简单、更安全
Hashable 是Swift最重要的协议,但是我们通常都注意不到这个协议。不是因为我们用不到,而是系统已经帮我们创建并实现了这个协议。
在Swift4.1之前,Hashable实现起来是比较复杂的,需要我们自己去计算一个 hashValue,如下

struct Jedi: Hashable {
    var name: String
    var darkSideUsage: Int

    var hashValue: Int {
        return name.hashValue ^ darkSideUsage.hashValue &* 16777619
    }
}

在4.1中,做到了简化,如下

struct Jedi: Hashable {
    var name: String
    var darkSideUsage: Int
}

虽然在4.1中做了简化,但是当我们需要自己实现的时候
例如,我们有很多属性,但是我们确定只需要一个属性就可以确定他的值,这个时候我们还是需要实现 hashValue

Swift 4.2改善了这个情况,引入了一个新的哈希结构体,它提供一个随机的、通用的哈希函数,来使这些更加简单。SE-0206: Hashable Enhancements
如果自己生成hashes,代码变得简洁许多

struct Jedi: Hashable {
    var name: String
    var darkSideUsage: Int

    func hash(into hasher: inout Hasher) {
        hasher.combine(name)
        hasher.combine(darkSideUsage)
    }
}

我们也可以使用 Hasher作为一个单独的哈希构造器来使用,独立的构造器最后要调用finalize()函数,例如:

let obiwan = Jedi(name: "Obi-wan Kenobi", darkSideUsage: 0)
let anakin = Jedi(name: "Anakin Skywalker", darkSideUsage: 90)

var hasher = Hasher()
hasher.combine(obiwan)
hasher.combine(anakin)
let hash = hasher.finalize()

这一切看起来没有什么不同,到最后我们都获取到了一个integer数值。有一个最大的不同就是,现在我们生成的 哈希值 是随机的,这就意味着给定对象的哈希值将在程序运行之间发生变化。

随机的哈希值是一个重要的特性,因为可预测的哈希值,让攻击者有可乘之机。事实上,有一款叫做 hash flooding的软件就可以实现攻击,如果我提前知道你的哈希算法,我可以很容易地生成许多具有相同哈希的不同对象。例如哈希算法是这样的

struct Jedi: Hashable {
    var name: String
    var darkSideUsage: Int

    var hashValue: Int {
        return name.hashValue &* 16777619
    }
}

他们可以使用相同的名称和不同的darkSideUsage属性生成任意数量的绝地物体。这些对象足够独特,可以多次添加到相同的集或字典中,但也足够相似,可以生成相同的散列。

for _ in 1...100 {
    set.insert(Jedi(name: "Obi-wan Kenobi", darkSideUsage: Int(arc4random_uniform(UInt32.max))))
}

我们创建了100个名为Obi-wan Kenobi的Jedi,每一个都有不同的darkSideUsage属性。
关于集合和字典的是如何工作的是很重要的。有一个误解,就是哈希值必须是唯一的,但是并非如此,如果是唯一的会更好,但是字典和集合完全可以保存具有相同哈希值的不同对象。
在上面的例子中,我们创建了100个Jedi具有相同哈希值的Jedi对象,我们做一个测试,从这个100个对象中取出我需要的对象,用时0.002s,但是如果10000个对象呢。
你可能觉得需要100*0.002 = 0.2s,但是我们却用了1.92s,如果是30000个对象,用时21.48s。
常规的字典和集合的时间复杂度是0(1),但是我们现在的是0(n^2)。就是因为我们的对象的哈希值相同造成的哈希碰撞。
假设现在有人创建100000这种伪相同的对象,这就可能直接导致程序崩溃。但是4.2解决了这个问题,它使用了一个名为 SipHash 的伪随机函数,该函数是专门设计的,因此攻击者无法再提前预测给定对象的哈希值。
现在你知道为什么 哈希洪水攻击为什么这么危险了吧。我们再举一个更真实的例子。
忙碌一天了,Jedi想要回家了,我们更新一下Jedi的结构,为他添加地址

struct Jedi: Hashable {
    var name: String
    var darkSideUsage: Int
    var address1: String
    var address2: String
    var city: String
    var state: String
    var postCode: String
    var country: String

    var hashValue: Int {
        return name.hashValue ^
            address1.hashValue ^
            address2.hashValue ^
            city.hashValue ^
            state.hashValue ^
            postCode.hashValue ^
            country.hashValue &* 16777619
    }
}

Jedi用到了姓名和每一个地址生成哈希值。但是,这些算法还是可以被攻击,我们还可以创建具有相同哈希值的不同对象,如下:

let test1 = Jedi(name: "test1", darkSideUsage: 0, address1: "1", address2: "2", city: "3", state: "4", postCode: "5", country: "6")
let test2 = Jedi(name: "test1", darkSideUsage: 0, address1: "2", address2: "1", city: "3", state: "4", postCode: "5", country: "6")
let test3 = Jedi(name: "test1", darkSideUsage: 0, address1: "3", address2: "2", city: "1", state: "4", postCode: "5", country: "6")

第一个对象使用1,2,3作为他的地址,第二个使用2,1,3作为地址,第三个使用3,2,1作为地址。因为实际存储的数据是相同的,哈希值也将是相同的——它们出现在不同的属性中并不重要,因为 a ^ b ^ c 产生与 c ^ a ^ b 相同的结果。
通过七个字符串属性,我们的属性有超过 5000 种这样的组合。 如果你为你的散列使用八个属性,则有超过 40,000 个,如果你使用十个,你将拥有超过 350 万个——这对攻击者来说都是微不足道的,因为它只是在不同的地方使用相同的字符串。
新的Hasher通过维护哈希状态来避免这种情况。 这就是使用 combine() 方法生成哈希的原因:每次将新属性添加到哈希中时,它都会与之前的状态相结合,确保添加的顺序很重要。
因此,我们可以重写我们的散列代码以使用新的 Swift 4.2 hash(into:)方法,如下所示:

func hash(into hasher: inout Hasher) {
    hasher.combine(name)
    hasher.combine(address1)
    hasher.combine(address2)
    hasher.combine(city)
    hasher.combine(state)
    hasher.combine(postCode)
    hasher.combine(country)
}

现在Jedi都会生成完全不同的哈希值,即使他们存储的字符串是相同的。

你可能感兴趣的:(关于 Hashable)