Crates.io | rs_sha1 |
lib.rs | rs_sha1 |
version | 0.1.3 |
source | src |
created_at | 2023-05-30 05:01:08.141129 |
updated_at | 2023-06-12 16:44:39.788683 |
description | `rs_sha1` is a Rust implementation of the SHA-1 cryptographic hash algorithm, part of the larger `rs_shield` project. This package provides SHA-1 hashing functionality in a standalone manner, ideal for when only SHA-1 is required. Alternatively, for those seeking a comprehensive set of cryptographic functions, this same algorithm is included within the broader `rs_shield` library bundle. The focus of `rs_sha1` and the larger project is on performance, safety, and openness, with a commitment to ongoing maintenance and enhancement. |
homepage | https://docs.rs/rs_shield/latest/rs_shield/ |
repository | https://github.com/Azgrom/RustyShield |
max_upload_size | |
id | 877577 |
size | 65,210 |
rs_sha1
rs_sha1
is a Rust crate offering the SHA-1 cryptographic hash algorithm. Designed for compatibility with Rust's libcore in a #![no_std]
context, it operates as a standalone crate for specialized use cases and can also function within a #![no_std]
, #![no_alloc]
environment, rendering it suitable for systems where dynamic memory allocation is untenable.
This implementation of SHA-1 is compliant with the Federal Information Processing Standards (FIPS) Publication 180-41. However, due to the nature of SHA-1's vulnerability to collision attacks, it is not recommended by the National Institute of Standards and Technology (NIST) for any application that requires collision resistance. This aligns with the guidance from NIST Special Publication 800-107:
"Federal agencies should stop using SHA-1 for [...] applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010."
Given the above, NIST recommendations imply that SHA-1 should not be used in the following contexts:
Yet, SHA-1 may still be utilized for non-security-critical applications, such as:
Please, consider these points with care, given the overall security objectives and risk tolerance of your application.
For access to a comprehensive range of cryptographic functions, rs_sha1
can be utilized as part of the rs_shield
library bundle.
Below are steps to use the rs_sha1
crate in your Rust projects:
Add the following line to your Cargo.toml
under the [dependencies]
section:
rs_sha1 = "0.1.*"
Use the functions provided by the rs_sha1
module in your code. Here's an example of how to create a SHA-1 hash from a string:
use rs_sha1::{HasherContext, Sha1Hasher};
let mut sha1hasher = Sha1Hasher::default();
sha1hasher.write(b"your string here");
let u64result = sha1hasher.finish();
let bytes_result = HasherContext::finish(&mut sha1hasher);
assert_eq!(u64result, 0x7D2C170805790AFA);
assert_eq!(format!("{bytes_result:02x}"), "7d2c170805790afac408349a9c266a123d1961be");
assert_eq!(format!("{bytes_result:02X}"), "7D2C170805790AFAC408349A9C266A123D1961BE");
assert_eq!(
bytes_result,
[
0x7D, 0x2C, 0x17, 0x08, 0x05, 0x79, 0x0A, 0xFA, 0xC4, 0x08, 0x34, 0x9A, 0x9C, 0x26, 0x6A, 0x12, 0x3D, 0x19, 0x61, 0xBE
]
)
For a more detailed exploration of rs_sha1
, an overview of other available cryptographic functions, and an introduction to the broader rs_shield
project, please consult the RustyShield project page on crates.io.
Potential contributors are encouraged to consult the contribution guidelines on our GitHub page.
This project is licensed under GPL-2.0-only.
Note: The references have been provided as per the best knowledge as of Jun 02, 2023.
National Institute of Standards and Technology. (2015). Secure Hash Standard (SHS). FIPS PUB 180-4 ↩
Linus Torvalds. (2005). Git: A distributed version control system. Software: Practice and Experience, 41(1), 79-88. DOI:10.1002/spe.1006 ↩
Krawczyk, H., Bellare, M., & Canetti, R. (1997). HMAC: Keyed-Hashing for Message Authentication. RFC 2104 ↩
Merkle, R. C. (1988). A Digital Signature Based on a Conventional Encryption Function. Link ↩
Bloom, B. H. (1970). Space/time trade-offs in hash coding with allowable errors. Communications of the ACM, 13(7), 422-426. DOI:10.1145/362686.362692 ↩