-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-type-systemArea: Type systemArea: Type systemC-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-lowLow priorityLow priorityT-langRelevant to the language teamRelevant to the language team
Description
The implementation of type_id from #10182 uses SipHash on various parameters depending on the type. The output size of SipHash is only 64-bits, however, making it feasible to find collisions via a Birthday Attack. I believe the code below demonstrates a collision in the type_id value of two different ty_structs:
use std::hash;
use std::hash::Streaming;
// I believe that this pretty much the same thing as hash_crate_independent() in ty.rs
// for a ty_struct on a 64-bit platform
fn hash_struct(local_hash: &str, node: u64) -> u64 {
let mut state = hash::default_state();
state.input([18]);
state.input(local_hash.as_bytes());
do node.iter_bytes(true) |bytes| { state.input(bytes); true };
state.result_u64()
}
fn main() {
// This represents two structures with different node values from a crate with a
// local_hash value of "local" that end up getting the same hash and thus,
// I think, the same type_id
assert!(hash_struct("local", 0x9e02c8943c336302) == hash_struct("local", 0x366a806b1d5f1b2));
}
kevincox, y21, kepexx, yurivish, matthunz and 5 more
Metadata
Metadata
Assignees
Labels
A-type-systemArea: Type systemArea: Type systemC-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-lowLow priorityLow priorityT-langRelevant to the language teamRelevant to the language team