wileyj / arm-test Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU General Public License v3.0
License: GNU General Public License v3.0
rust-crypto is unmaintained; switch to a modern alternative
Details | |
---|---|
Status | unmaintained |
Package | rust-crypto |
Version | 0.2.36 |
URL | DaGenix/rust-crypto#440 |
Date | 2016-09-06 |
The rust-crypto
crate has not seen a release or GitHub commit since 2016,
and its author is unresponsive.
NOTE: The (old) rust-crypto
crate (with hyphen) should not be confused with
similarly named (new) RustCrypto GitHub Org (without hyphen). The GitHub Org
is actively maintained.
We recommend you switch to one of the following crates instead, depending on
which algorithms you need:
x25519-dalek
ed25519-dalek
ring
:
aes-gcm
, aes-gcm-siv
, aes-siv
, chacha20poly1305
, xsalsa20poly1305
aes
, cast5
, des
sha2
, sha3
, blake2
, ripemd160
sha-1
, [md-5
])hkdf
cmac
, hmac
, pmac
, poly1305
pbkdf2
aes-ctr
, chacha20
, hc-256
, salsa20
secp256k1
:
orion
:
See advisory page for additional details.
asdfsafasdsdaf
test milestone 2
Miscomputation when performing AES encryption in rust-crypto
Details | |
---|---|
Package | rust-crypto |
Version | 0.2.36 |
Date | 2022-02-28 |
The following Rust program demonstrates some strangeness in AES encryption - if you have an immutable key slice and then operate on that slice, you get different encryption output than if you operate on a copy of that key.
For these functions, we expect that extending a 16 byte key to a 32 byte key by repeating it gives the same encrypted data, because the underlying rust-crypto functions repeat key data up to the necessary key size for the cipher.
use crypto::{
aes, blockmodes, buffer,
buffer::{BufferResult, ReadBuffer, WriteBuffer},
symmetriccipher,
};
fn encrypt(
key: &[u8],
iv: &[u8],
data: &str,
) -> Result<String, symmetriccipher::SymmetricCipherError> {
let mut encryptor =
aes::cbc_encryptor(aes::KeySize::KeySize256, key, iv, blockmodes::PkcsPadding);
let mut encrypted_data = Vec::<u8>::new();
let mut read_buffer = buffer::RefReadBuffer::new(data.as_bytes());
let mut buffer = [0; 4096];
let mut write_buffer = buffer::RefWriteBuffer::new(&mut buffer);
loop {
let result = encryptor.encrypt(&mut read_buffer, &mut write_buffer, true)?;
encrypted_data.extend(
write_buffer
.take_read_buffer()
.take_remaining()
.iter()
.copied(),
);
match result {
BufferResult::BufferUnderflow => break,
BufferResult::BufferOverflow => {}
}
}
Ok(hex::encode(encrypted_data))
}
fn working() {
let data = "data";
let iv = [
0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE,
0xFF,
];
let key = [
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,
0x0F,
];
// The copy here makes the code work.
let key_copy = key;
let key2: Vec<u8> = key_copy.iter().cycle().take(32).copied().collect();
println!("key1:{} key2: {}", hex::encode(&key), hex::encode(&key2));
let x1 = encrypt(&key, &iv, data).unwrap();
println!("X1: {}", x1);
let x2 = encrypt(&key2, &iv, data).unwrap();
println!("X2: {}", x2);
assert_eq!(x1, x2);
}
fn broken() {
let data = "data";
let iv = [
0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE,
0xFF,
];
let key = [
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,
0x0F,
];
// This operation shouldn't affect the contents of key at all.
let key2: Vec<u8> = key.iter().cycle().take(32).copied().collect();
println!("key1:{} key2: {}", hex::encode(&key), hex::encode(&key2));
let x1 = encrypt(&key, &iv, data).unwrap();
println!("X1: {}", x1);
let x2 = encrypt(&key2, &iv, data).unwrap();
println!("X2: {}", x2);
assert_eq!(x1, x2);
}
fn main() {
working();
broken();
}
The output from this program:
Running `target/host/debug/rust-crypto-test`
key1:000102030405060708090a0b0c0d0e0f key2: 000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f
X1: 90462bbe32965c8e7ea0addbbed4cddb
X2: 90462bbe32965c8e7ea0addbbed4cddb
key1:000102030405060708090a0b0c0d0e0f key2: 000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f
X1: 26e847e5e7df1947bf82a650548a7d5b
X2: 90462bbe32965c8e7ea0addbbed4cddb
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"26e847e5e7df1947bf82a650548a7d5b"`,
right: `"90462bbe32965c8e7ea0addbbed4cddb"`', src/main.rs:83:5
Notably, the X1 key in the broken()
test changes every time after rerunning the program.
See advisory page for additional details.
Stack overflow in rustc_serialize when parsing deeply nested JSON
Details | |
---|---|
Package | rustc-serialize |
Version | 0.3.24 |
Date | 2022-01-01 |
When parsing JSON using json::Json::from_str
, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process.
Example code that triggers the vulnerability is
fn main() {
let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000));
}
serde is recommended as a replacement to rustc_serialize.
See advisory page for additional details.
Potential segfault in the time crate
Details | |
---|---|
Package | time |
Version | 0.1.44 |
URL | time-rs/time#293 |
Date | 2020-11-18 |
Patched versions | >=0.2.23 |
Unaffected versions | =0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6 |
Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
The affected functions from time 0.2.7 through 0.2.22 are:
time::UtcOffset::local_offset_at
time::UtcOffset::try_local_offset_at
time::UtcOffset::current_local_offset
time::UtcOffset::try_current_local_offset
time::OffsetDateTime::now_local
time::OffsetDateTime::try_now_local
The affected functions in time 0.1 (all versions) are:
at
at_utc
now
Non-Unix targets (including Windows and wasm) are unaffected.
Pending a proper fix, the internal method that determines the local offset has been modified to always return None
on the affected operating systems. This has the effect of returning an Err
on the try_*
methods and UTC
on the non-try_*
methods.
Users and library authors with time in their dependency tree should perform cargo update
, which will pull in the updated, unaffected code.
Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
No workarounds are known.
See advisory page for additional details.
stdweb is unmaintained
Details | |
---|---|
Status | unmaintained |
Package | stdweb |
Version | 0.4.20 |
URL | koute/stdweb#403 |
Date | 2020-05-04 |
The author of the stdweb
crate is unresponsive.
Maintained alternatives:
See advisory page for additional details.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.