> Fiona Ebner <f.eb...@proxmox.com> hat am 15.01.2025 10:39 CET geschrieben:
>
>
> Am 14.01.25 um 11:03 schrieb DERUMIER, Alexandre:
> >>> If we do need lookup, an idea to get around the character limit is
> >>> using
> >>> a hash of the information to generate the node name, e.g.
> >>> hash("fmt-$volid@$snapname"), hash("file-$volid@$snapname") or
> >>> whatever
> >
> > yes, I think it should works
> >
> >>> is actually needed as unique information. Even if we only use
> >>> lowercase
> >>> letters, we have 26 base chars, so 26^31 possible values.
> >
> > yes, I was think about a hash too, but I was not sure how to convert it
> > to the alphanum characters (valid char : alphanum , ‘-’, ‘.’ and ‘_’.
> > )
> >
> >
> >
> >>> So hashes with up to
> >>>
> >>>> math.log2(26**31)
> >>> 145.71363126237387
> >>>
> >>> bits can still fit, which should be more than enough. Even with an
> >>> enormous number of 2^50 block nodes (realistically, the max values we
> >>> expect to encounter are more like 2^10), the collision probability
> >>> (using a simple approximation for the birthday problem) would only be
> >>>
> >>>> d=2**145
> >>>> n=2**50
> >>>> 1 - math.exp(-(n*n)/(2*d))
> >>> 1.4210854715202004e-14
> >
> > yes, should be enough
> >
> > a simple md5 is 128bit,
> > sha1 is 160bit (it's 150bits space with extra -,.,- characters)
> >
> > Do you known a good hash algorithm ?
>
> I'm not too well-read in cryptography, but AFAIK, you can shorten the
> result of sha256 to get a good hash algorithm with fewer bits. We could
> also have the node-name start with a "h" to make sure it doesn't start
> with a number and then use base32 for the remaining 30 characters. I.e.
> we could take the first 150 bits (32^30 = 2^150) from the sha256 hash
> and convert that to base32.
>
> @Shannon @Fabian please correct me if I'm wrong.
IMHO this isn't really a cryptographic use case, so I'd not worry too much
about any of that.
basically what we have is the following situation:
- we have some input data (volid+snapname)
- we have a key derived from the input data (block node name)
- we have a value (block node)
- we need to be be able to map back the block node (name) to the input data
sometimes we need to allocate a second block node temporarily for a given input
data (right?), and we can't rename block nodes, so there might be more than one
key value (block node name) for a key. to map back from a block node name to
the volid+snapname, we can hash the input data and then use that (shortened)
hash as the middle part of the block node name (with a counter as last part and
some static/drive-related prefix). the only thing we need to ensure is that the
hash is good enough to avoid accidental collisions (given the nature of the
input data, I don't think we have to worry about non-accidental collisions
either unless we choose a very basic checksum, but even if that were possible,
an attacker could only mess with data of a VM where they can already add/remove
images anyway..), and that we never re-use a block node name for something that
doesn't match its input data (I have to admit I lost track a bit of whether
that invariant can hold?).
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
