ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
causal has quit [Quit: WeeChat 3.6]
dc740 has quit [Remote host closed the connection]
explore has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
neceve has joined #rust-embedded
brazuca has quit [Quit: Client closed]
neceve has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <skylardive1> Hello, I am trying to port this code to my no_std project, but it appears it was written in 2018. I am relatively new to Rust, so I'm not familiar with methods like std::heap (which doesn't exist anymore) - https://github.com/gnzlbg/libc_mallocator/blob/master/src/lib.rs
<re_irc> <skylardive1> pub struct LibcMalloc;
<re_irc> unsafe impl Alloc for LibcMalloc {
<re_irc> unsafe fn alloc(&mut self, layout: core::alloc::Layout) -> Result<*mut u8, AllocErr> {
<re_irc> #[inline]
<re_irc> <skylardive1> Ok, I have tried following the logic for the examples on docs, does this look wrong to anyone?
<re_irc> <skylardive1> const ARENA_SIZE: usize = 128 * 1024;
<re_irc> #[repr(C, align(4096))]
<re_irc> struct SimpleAllocator {
<re_irc> const MAX_SUPPORTED_ALIGN: usize = 4096;
<re_irc> <diondokter> skylardive1: I don't know much about the current allocator API's, but maybe have a look at this one for inspiration: https://crates.io/crates/linked_list_allocator
<re_irc> <skylardive1> diondokter: that one is well used?
<re_irc> <diondokter> Well, it has almost 400K downloads, so at least it's not little used ;)
<re_irc> <skylardive1> does this work on Linux or is it for bare metal only?
<re_irc> <diondokter> Its main use is bare metal. Idk if it can be used on Linux. But why would you not use the normal allocator on Linux?
<re_irc> <skylardive1> well, i am using malloc
<re_irc> <skylardive1> error[E0015]: cannot call non-const fn `malloc` in statics
<re_irc> |
<re_irc> --> src/main.rs:24:19
<re_irc> 24 | arena: unsafe{libc::malloc(ARENA_SIZE)},
<re_irc> <K900> Stop trying to bolt together five different code examples into one working allocator
<re_irc> <skylardive1> K900: where do you see five? I sent two only
<re_irc> <datdenkikniet> are you 100% certain you need a custom allocator?
<re_irc> <skylardive1> the first one is using methods that are no longer in the rust language
<re_irc> <K900> That was a figure of speech
<re_irc> <datdenkikniet> * need/want
<re_irc> <skylardive1> how is this able to be so simple and neat?
<re_irc> <K900> By being wrong
<re_irc> <skylardive1> haha, how is it wrong?
<re_irc> <K900> It ignores alignment requirements
<re_irc> <K900> If you're going to yoink someone else's code, yoink this
<re_irc> <skylardive1> very well, code will be yoinked
explore has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
causal has joined #rust-embedded
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <newam> I learned of p256-cortex-m4-sys (https://crates.io/crates/p256-cortex-m4-sys) from this chat, if anyone else is using that I did a re-write of the C portions in rust: https://crates.io/crates/p256-cm4
<re_irc> The C version is still better if you need to use the configuration in the header file. The only real benefit of the rust re-write is that is doesn't require an external assembler/compiler.
<re_irc> <dirbaio> oh using "global_asm!", so nice
<re_irc> <dirbaio> i've been using the x25519 asm code from that same author, i'll definitely yoink the idea :D
<re_irc> <newam> Oooo I didn't know they had x25519 as well
<re_irc> <dirbaio> it's faaaaaast
<re_irc> <newam> > The library uses only 1892 bytes of code space in compiled form, uses 368 bytes of stack and runs one scalar multiplication in 548 873 cycles on Cortex-M4, which is speed record as far as I know.
<re_irc> Wow faster and smaller than p256
<re_irc> <dirbaio> yeah curve25519 is the best curve out there, much faster and apparently more secure than the nist curves
<re_irc> <dirbaio> i've extended that to do ed25519 too
<re_irc> <newam> The problem is usually finding a fast implementation 😆
<re_irc> <dirbaio> but i'm a bit scared of opensourcing it because it's not constant time, so it's only really useful for verify, not sign 😓
<re_irc> <dirbaio> which is all that I needed
<re_irc> <newam> some day we will all have crypto coprocessors :P
<re_irc> <dirbaio> "Emill/X25519-Cortex-M4" is allegedly faster than the hardware x25519 in nrf's cc310 crypto coprocessor 😂
<re_irc> <newam> Wouldn't surprise me, "Emill/P256-Cortex-M4" is faster than ST's hardware PKA:
<re_irc> | Implementation | Signing Cycles (appx) | Verify Cycles (appx) | Flash Size (appx) |
<re_irc> |----------------|-----------------------|----------------------|-------------------|
<re_irc> | Hardware PKA | 5,211,859 | 10,516,860 | 1,582 B |
<re_irc> <newam> Wouldn't surprise me, "Emill/P256-Cortex-M4" is faster than ST's hardware PKA:
<re_irc> |----------------|-----------------------|----------------------|-------------------|
<re_irc> | Implementation | Signing Cycles (appx) | Verify Cycles (appx) | Flash Size (appx) |
<re_irc> | Hardware PKA | 5,211,859 | 10,516,860 | 1,582 B |
<re_irc> <newam> * RustCrypto
<re_irc> | Implementation | Signing Cycles (appx) | Verify Cycles (appx) | Flash Size (appx) |
<re_irc> |----------------|-----------------------|----------------------|-------------------|
<re_irc> <newam> Wouldn't surprise me, "Emill/P256-Cortex-M4" is faster than ST's hardware PKA:
<re_irc> | Hardware PKA | 5,211,859 | 10,516,860 | 1,582 B |
<re_irc> <dirbaio> 10x faster? wtf
<re_irc> <newam> yup
<re_irc> <dirbaio> just, wow
brazuca has quit [Quit: Client closed]
<re_irc> <chrysn (@chrysn:matrix.org)> that is impressive. granted, the nRF is not the fastest ECC on the block, but it still outperformed the last reference software algorithms i've seen it compared with by a factor of 5-10 in Kietzmann et al (https://eprint.iacr.org/2021/058.pdf) figure 4
<re_irc> <thalesfragoso> dirbaio: I wouldn't say that, it has a few points with low order, and that's gets worse because the author says you don't need to care about them, as in, you don't need to validate public keys
<re_irc> <thalesfragoso> So a good amount of libraries don't
<re_irc> <thalesfragoso> Some people say it's more secure than nist curves because they do not trust nist
<re_irc> <newam> thalesfragoso: Do you have a link for that? Would love to read more, always trying to expand my crypto knowledge.
<re_irc> <thalesfragoso> newam: I like this question as a good start point:
<re_irc> <thalesfragoso> PS: I'm not an expert in this, just a curious person
<re_irc> <dirbaio> "don't trust NIST" Is reasonable, given its history 😂
<re_irc> <dirbaio> * already a good argument in favor of curve25519
<re_irc> <dirbaio> given its documented history of sabotage :D
<re_irc> <thalesfragoso> Sure, but that isn't really an argument in favor of curve25519, just one against nist
<re_irc> <newam> The logical conclusion is to trust no one and implement your own crypto, right? 🙃
<re_irc> <dirbaio> there's some objective comparisons here which I barely understand :P http://safecurves.cr.yp.to/index.html
dc740 has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
<re_irc> <thalesfragoso> curve25519 is nice: fast and easier to implement correctly (e.g. with respect to constant time), I just would like that they talked more about the weak keys, but what you usually get is the opposite, people placing "you don't need to validate public keys" as one of the biggest benefits of it.
<re_irc> <dirbaio> it is true you don't have to, for ECDH
neceve has quit [Ping timeout: 252 seconds]
<re_irc> <thalesfragoso> dirbaio: Well, the triple handshake attack disagrees with you
<re_irc> <thalesfragoso> The website disregards contributory behavior as a niche thing, but TLS itself was successfully attacked due to lack of it
bjc has joined #rust-embedded
<re_irc> <dirbaio> huh, l have to read about it then 😅
<re_irc> <newam> Does anyone have a crate that uses the "embedded_hal_async" SPI traits for a slave?
<re_irc> I've forgotten some of the async idioms after not touching it for a year :S
<re_irc> <dirbaio> for slave mode? the traits are for master mode only
<re_irc> <newam> Sorry as in a device that uses the traits, rather than a HAL that implements the traits.
<re_irc> <dirbaio> ah so for a driver
<re_irc> <newam> 🤦♂️ yeah, driver, how did I suddenly loose that word from my vocabulary?
<re_irc> <newam> Thanks!
<re_irc> <thalesfragoso> dirbaio: It's a contrived one, but still
<re_irc> <thalesfragoso> It gets bad if you support renegotiation
<re_irc> <thalesfragoso> (without also supporting the extended master secret extension)
<re_irc> <thalesfragoso> And enforcing it
<re_irc> <newam> Was that meant for a different chat...?
<re_irc> Random PDF seems sketchy
<re_irc> <James Munns> Deleting, just in case.
<re_irc> <newam> Good call either way.
dc740 has quit [Remote host closed the connection]