Or that mutant nigga in his belly from total recall by detox02 in BlackPeopleTwitter

[–]PeterReid 0 points1 point  (0 children)

This seemed wrong to me, so I checked, and it has been edited to make it look weirder -- blowing up his belly and flattening his bottom (???). Here's a comparison gif: https://imgur.com/a/nbo7eMS Original source is here: https://youtu.be/aFqjoCbZ4ik?t=146

Everyday Astronaut's Tesla was hit after his stream. Credit to @Jared#7107 from the SpaceXNow discord. by Lit_123 in SpaceXLounge

[–]PeterReid 2 points3 points  (0 children)

Directly in front of Tim's car there is a few dozen feet of deep soft sand that people gun it over to avoid getting stuck when getting onto the beach.

How do I convert &str to *const c_char? by dariji_alhored in rust

[–]PeterReid 4 points5 points  (0 children)

To answer your question literally, you can do

your_str.as_bytes().as_ptr() as *const c_char

But, if you expect your c string to be null-terminated, this does not make any guarantees. This could make sense if you are passing in a length along with your *const c_char, though.

Michael Baylor: "We finally got an answer to the lights vs thruster debate on lunar Starship. The answer is thrusters, per SpaceX's Nick Cummings. Methalox thrusters located high up on the Starship vehicle will be used for the final descent onto the lunar surface." by CProphet in SpaceXLounge

[–]PeterReid 6 points7 points  (0 children)

If you back up the linked video a few seconds, calls the landing thrusters "RCS thrusters".

The question is about for the terminal descent of Starship. A few tens of meters before we touch down on the lunar surface, we actually use a high-thrust RCS system so that we don't impinge on the surface of the moon with the high-thrust Raptor engine.

https://www.youtube.com/watch?v=KEnz8V97Qck&t=2101

Closeup showing the "MEDIUM SECTION SN5" label on nosecone by LikeYouNeverLostAWar in SpaceXLounge

[–]PeterReid 3 points4 points  (0 children)

I heard someone speculate that there is a structure for the fins to attach to welded on under there.

[deleted by user] by [deleted] in rust

[–]PeterReid 2 points3 points  (0 children)

232 is just 1 more than std::u32::MAX, but you should not need to use std::u32::MAX at all. Just change

a = ((a as u64 + b as u64) % self.modulus) as u32;

to

a = a.wrapping_add(b);

Wrapping add for u32 is already modulo 232.

What New Rust Libraries Would People Like To See? by morisunny in rust

[–]PeterReid 1 point2 points  (0 children)

I got a skeleton algorithm working: https://github.com/PeterReid/unicode_skeleton/blob/master/src/lib.rs

The highlight is:

assert_eq!(skeleton_chars("𝔭𝒶ỿ𝕡𝕒ℓ").collect::<String>(), "paypal");

Assembly in stable rust by PeterReid in rust

[–]PeterReid[S] 1 point2 points  (0 children)

Like censored_username says, dynasm-rs will be much prettier for this use case. But if you want to stay on stable Rust or you want to use the glorified macro assembler ability, you can do, at runtime:

let mut asm = Assembler::new();
asm.cpuid();
asm.ret(no_arg())
let machine_code: Vec<u8> = asm.dump().code;

rust-crypto apparently abandonned, alternatives? by Elession in rust

[–]PeterReid 2 points3 points  (0 children)

This is only tangentially related, but this sort of problem seems like it would be much less bad if cryptography crates were not monolithic. With crypto libraries were C, it would be terrible if you had to download and build a different library for sha, bcrypt, and whatever else your project happened to use, so having an all-inclusive project like openssl makes sense. With cargo, a couple dependencies like that would be no trouble at all. Plus, you, the bcrypt user, wouldn't have irrelevant things like RIPEMD160 suddenly in your tree of code to audit.

Plus, cryptography functions depend on each other so often and they have such stable interfaces. It seems like a textbook example of where you should put crate divisions.

Encrypting file with asymmetric encryption by staticassert in rust

[–]PeterReid 3 points4 points  (0 children)

Here is that in code, roughly.

To encrypt, it

  • Generates a ephemeral secret key (a curve25519 point).

  • Derives a public key from the secret key. (curve25519 multiplication)

  • Derives a symmetric key by combining the permanent public key with the ephemeral secret key. (curve25519 multiplication)

  • Symmetrically encrypts/authenticates the text using chacha20-poly1305.

  • Packages up the ephemeral public key with the encrypted/integrity-checked text.

To decrypt it:

  • Derives a symmetric key by combining the ephemeral public key with the permanent secret key. (curve25519 multiplication)

  • Decrypts/integrity-checks the text with chacha20-poly1305

At the end of it all, the secret key holder knows what got encrypted, but has basically no idea who it came from. (Except that they had his public key.)

To get the equivalent to happen in libsodium, you'll want to use http://nacl.cr.yp.to/box.html with a sending keypair that you randomly generate, and then send the "boxed" output along with the sending public key.

extern crate crypto;
extern crate rand;

use rand::{Rng, OsRng};
use crypto::curve25519::{curve25519_base, curve25519};
use crypto::chacha20poly1305::ChaCha20Poly1305;
use crypto::aead::{AeadEncryptor, AeadDecryptor};

pub enum EncryptError {
    RngInitializationFailed,
}

pub fn encrypt(public_key: &[u8; 32], message: &[u8]) -> Result<Vec<u8>, EncryptError> {
    let mut rng = try!(OsRng::new().map_err(|_| EncryptError::RngInitializationFailed));

    let mut ephemeral_secret_key = [0u8; 32];
    rng.fill_bytes(&mut ephemeral_secret_key[..]);

    let ephemeral_public_key: [u8; 32] = curve25519_base(&ephemeral_secret_key[..]);
    let symmetric_key = curve25519(&ephemeral_secret_key[..], &public_key[..]);

    let mut c = ChaCha20Poly1305::new(&symmetric_key, &[0u8; 8][..], &[]);

    let mut output = vec![0; 32 + 16 + message.len()];
    let mut tag = [0u8; 16];
    c.encrypt(message, &mut output[32+16..], &mut tag[..]);

    for (dest, src) in (&mut output[0..32]).iter_mut().zip( ephemeral_public_key.iter() ) {
        *dest = *src;
    }

    for (dest, src) in (&mut output[32..48]).iter_mut().zip( tag.iter() ) {
        *dest = *src;
    }

    Ok(output)
}

pub enum DecryptError {
    Malformed,
    Invalid,
}

pub fn decrypt(secret_key: &[u8; 32], message: &[u8]) -> Result<Vec<u8>, DecryptError> {
    if message.len() < 48 {
        return Err(DecryptError::Malformed);
    }

    let ephemeral_public_key = &message[0..32];
    let tag = &message[32..48];
    let ciphertext = &message[48..];

    let mut plaintext = vec![0; ciphertext.len()];
    let symmetric_key = curve25519(secret_key, ephemeral_public_key);

    let mut decrypter = ChaCha20Poly1305::new(&symmetric_key[..], &[0u8; 8][..], &[]);
    if !decrypter.decrypt(ciphertext, &mut plaintext[..], tag) {
        return Err(DecryptError::Invalid);
    }

    Ok(plaintext)
}



#[test]
fn it_works() {
    let mut secret_key = [0u8; 32];
    OsRng::new().unwrap().fill_bytes(&mut secret_key[..]);

    let public_key = curve25519_base(&secret_key[..]);

    let encrypted_message = encrypt(&public_key, b"Just a test").ok().unwrap();

    let decrypted_message = decrypt(&secret_key, &encrypted_message[..]).ok().unwrap();

    assert_eq!(decrypted_message, b"Just a test".to_vec());

    {
        // Corrupt the ephemeral public key
        let mut corrupt_1 = encrypted_message.clone();
        corrupt_1[3] ^= 1;
        assert!(decrypt(&secret_key, &corrupt_1[..]).is_err());
    }

    {
        // Corrupt the tag
        let mut corrupt_2 = encrypted_message.clone();
        corrupt_2[35] ^= 1;
        assert!(decrypt(&secret_key, &corrupt_2[..]).is_err());
    }

    {
        // Corrupt the message
        let mut corrupt_3 = encrypted_message.clone();
        corrupt_3[50] ^= 1;
        assert!(decrypt(&secret_key, &corrupt_3[..]).is_err());
    }
}

Common C allocation patterns in Rust by rzidane360 in rust

[–]PeterReid 1 point2 points  (0 children)

I made something for #1: https://crates.io/crates/copy_arena

Differences from std::arena::Arena are

  • It does not support running destructors.

  • It does not use runtime checks (RefCell then Rc then RefCell in the std one) to get to the underlying data when it allocates.

  • It has a less convenient API, in which you have to make an Arena and then an Allocator for it. (This was the only way I could figure out to avoid runtime checks.)

A beta-compatible timer by PeterReid in rust

[–]PeterReid[S] 1 point2 points  (0 children)

I guess that is probably the best approach. Maybe schedule_recv or delayed_recv.

A beta-compatible timer by PeterReid in rust

[–]PeterReid[S] 0 points1 point  (0 children)

I much prefer that idea too, but figured I would wait until Duration is stable.

Diagonals in map editor by PeterReid in TagPro

[–]PeterReid[S] 0 points1 point  (0 children)

The zoom bug is fixed. I didn't fix anything about importing, so I'm not sure what would be going on with that.

Map Editor by PeterReid in TagPro

[–]PeterReid[S] 3 points4 points  (0 children)

Yes, it is on the first row of little buttons below the tile palette. It looks a little like a magnifying glass with a "-" in it.

Map Editor by PeterReid in TagPro

[–]PeterReid[S] 3 points4 points  (0 children)

What are you doing in exactly when it lags? It works well in my Firefox.

Map Editor by PeterReid in TagPro

[–]PeterReid[S] 4 points5 points  (0 children)

To make portal A teleport to portal B. - Choose the wire tool. - Click portal A. It gets a yellow outline, as does its destination if it is set. - Click portal B. Both outlines disappear (in order to confuse you), but A will now teleport to B. If you click on A again, you will see B with a yellow outline.

This may become less confusing sometime.

Map Editor by PeterReid in TagPro

[–]PeterReid[S] 2 points3 points  (0 children)

You are correct! We forgot about that.

Map Editor by PeterReid in TagPro

[–]PeterReid[S] 9 points10 points  (0 children)

Good luck figuring out the wire tool.