in Tokyo. • Focusing on development of privacy solutions to blockchain-based systems. ◦ Zero-knowledge proving systems ◦ TEE • Core dev. of Zerochain ◦ https://github.com/LayerXcom/zero-chain Osuke Sudo Twitter: @zoom_zoomzo
Without error-prone manual memory allocations and deallocations. • Ownership model ◦ Resources can only have one owner. ◦ let x = vec![1, 2, 3]; : x owns resource vec![1, 2, 3] . ◦ let y = x; : Ownership of resource vec![1, 2, 3] moves to y . ◦ let y = &x; : y borrows ownership of resource vec![1, 2, 3] from x . ◦ Compiler can know variable “lifetime”.
and in doing so they love to "optimize away" unnecessary zeroing calls. • Debuggers or remote machines can access leftover values in memory. • Sensitive data must never be accessible. ◦ private key, password, randomness... • Heartbleed bug in OpenSSL ◦ It leads to the leak of memory contents from the server to the client and vice versa.
memory location with the given value and guaranteed to not be elided or reordered by the compiler. • compiler_fence : Restricts the kinds of memory re-ordering the compiler is allowed to do. • Ordering::SeqCst : No re-ordering of reads and writes across this point is allowed.
exists a relationship between the secret data and the execution time of your code. • It’s best practice to write code that is “constant-time” to prevent timing leaks. ◦ More precisely, “Secret-independent resource usage” P A S S W O R D A A S S W O R D P A S S W O R D P A S S W O D D
unexpected or random data as inputs to a program. • In paticular, useful for hash functions, serializers, or parsers.. • Lots of bugs are founded by fuzzing. ◦ ref: https://github.com/rust-fuzz/trophy-case • tools ◦ cargo-fuzz ◦ honggfuzz-rs
lints to catch common mistakes and improve your Rust code. • cargo-audit ◦ Audit Cargo.lock ﬁles for crates with security vulnerabilities reported to the RustSec Advisory Database. • cargo-crev ◦ A cryptographically veriﬁable code review system for the cargo (Rust) package manager.