Support for Standard Hex dumps like Sha256 and Md5

[comath]

I'm using this to save some memory working with a large amount of objects that each have a md5, sha256, sha512, etc...

I was wonder if you were interested in adding some official support for these common hex dumps?

For example, for md5:

#[derive(Debug,Hash,PartialEq,Eq,Default)]
pub struct Md5 {
    hash: [u8;16],
}
impl FromHex for Md5 {
....
}
impl FromHex for Md5 {
....
}

I'm working on getting this to integrate with Serde.

[KokaKiwi]

Actually in the latest version 0.4.2, serde is supported for serializing/de-serializing hex strings: https://docs.rs/hex/0.4.2/hex/serde/index.html

Also, FromHex is implemented for many bytes arrays of many sizes (kinda arbitrarily for the moment until const generics are a thing): https://github.com/KokaKiwi/rust-hex/blob/v0.4.2/src/lib.rs#L209-L219

(kinda hope it answers your question as i don't understand exactly what you're asking)

[comath]

Yea, I think you have everything covered, I want to support deserializing json blobs like:

#[derive(Debug,Serialize, Deserialize)]
pub struct RlData {
    md5: Md5,
    sha1: Sha1,
    sha256: Sha256,
    sha384: Sha384,
    sha512: Sha512,
}

instead of having to specify the byte arrays at each step. Maybe just a set of these:

pub type Md5Hex = [u8;16];
pub type Sha1Hex = [u8;20];
pub type Sha256Hex = [u8;32];
pub type Sha512Hex = [u8;64];
pub type Sha384Hex = [u8;64];

[KokaKiwi]

Well for this you can do this for example then:

#[derive(Debug,Serialize, Deserialize)]
pub struct RlData {
    #[serde(with = "hex")]
    md5: [u8;16],
    #[serde(with = "hex")]
    sha1: [u8;20],
    #[serde(with = "hex")]
    sha256: [u8;32],
    #[serde(with = "hex")]
    sha384: [u8;64],
    #[serde(with = "hex")]
    sha512: [u8;64],
}

[comath]

I think a list of common hashes so we can code that by name (and not have to remember the sizes) would be helpful. This is just a cherry on top of a great crate, so it's just a quality of life thing.

[piegamesde]

I think the proposal here is strictly weaker than and superseded by #65. Furthermore, all cryptographic libraries that I've ever used all relied on type aliases, although they mainly used generic-array instead of plain bytes.

[comath]

Sounds good, I'm happy to close this.