Noratrieb/website
1
0
Fork 0
mirror of https://github.com/Noratrieb/website.git synced 2026-01-14 08:55:01 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

move submodules in-tree

Browse source
This commit is contained in:
nora 2025-08-13 20:47:44 +02:00
parent 57c4a239da
commit 830045ee2f
238 changed files with 41955 additions and 187 deletions
Download patch file Download diff file Expand all files Collapse all files

1
blog/.envrc Normal file
View file

@ -0,0 +1 @@
use nix

5
blog/.gitignore vendored Normal file
View file

@ -0,0 +1,5 @@
/.idea
/.vscode
/public
/helpers/*/target

0
blog/.hugo_build.lock Normal file
View file

4
blog/README.md Normal file
View file

@ -0,0 +1,4 @@
# [noratrieb.dev/blog](https://noratrieb.dev/blog)
a very good blog

6
blog/archetypes/default.md Normal file
View file

@ -0,0 +1,6 @@
---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
---

15
blog/config.toml Normal file
View file

@ -0,0 +1,15 @@
baseURL = "/blog/"
languageCode = "en-us"
title = "Noratrieb's blog"
theme = "terminal"
[params]
contentTypeName = "posts"
centerTheme = true
[params.logo]
logoText = "noratrieb's blog"
# Let me use HTML :3
[markup.goldmark.renderer]
unsafe = true

243
blog/content/posts/box-is-a-unique-type.md Normal file
View file

@ -0,0 +1,243 @@
+++
title = "Box Is a Unique Type"
date = "2022-07-23"
author = "Noratrieb"
tags = ["rust", "unsafe code"]
keywords = ["box", "noalias"]
description = "About better aliasing semantics for `Box<T>`"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
We have all used `Box<T>` before in our Rust code. It's a glorious type, with great ergonomics
and flexibility. We can use it to put our values on the heap, but it can do even more
than that!
```rust
struct Fields {
a: String,
b: String,
}
let fields = Box::new(Fields {
a: "a".to_string(),
b: "b".to_string()
});
let a = fields.a;
let b = fields.b;
```
This kind of partial deref move is just one of the spectacular magic tricks box has up its sleeve,
and they exist for good reason: They are very useful. Sadly we have not yet found a way to generalize all
of these to user types as well. Too bad!
Anyways, this post is about one particularly subtle magic aspect of box. For this, we need to dive
deep into unsafe code, so let's get our hazmat suits on and jump in!
# An interesting optimization
We have this code here:
```rust
fn takes_box_and_ptr_to_it(mut b: Box<u8>, ptr: *const u8) {
let value = unsafe { *ptr };
*b = 5;
let value2 = unsafe { *ptr };
assert_ne!(value, value2);
}
let b = Box::new(0);
let ptr: *const u8 = &*b;
takes_box_and_ptr_to_it(b, ptr);
```
There's a function, `takes_box_and_ptr_to_it`, that takes a box and a pointer as parameters. Then,
it reads a value from the pointer, writes to the box, and reads a value again. It then asserts that
the two values aren't equal. How can they not be equal? If our box and pointer point to the same
location in memory, writing to the box will cause the pointer to read the new value.
Now construct a box, get a pointer to it, and pass the two to the function. Run the program...
... and everything is fine. Let's run it in release mode. This should work as well, since the optimizer
isn't allowed to change observable behaviour, and an assert is very observable. Run the program...
```
thread 'main' panicked at 'assertion failed: `(left != right)`
left: `0`,
right: `0`', src/main.rs:5:5
```
Hmm. That's not what I've told would happen. Is the compiler broken? Is this a miscompilation?
I've heard that those do sometimes happen, right?
Trusting our instincts that "it's never a miscompilation until it is one", we assume that LLVM behaved
well here. But what allows it to make this optimization? Taking a look at the generated LLVM-IR (by using
`--emit llvm-ir -O`, the `-O` is important since rustc only emits these attributes with optimizations on)
reveals the solution: (severely shortened to only show the relevant parts)
```llvmir
define void @takes_box_and_ptr_to_it(i8* noalias %0, i8* %ptr) {
```
See the little attribute on the first parameter called `noalias`? That's what's doing the magic here.
`noalias` is an LLVM attribute on pointers that allows for various optimizations. If there are two pointers,
and at least one of them is `noalias`, there are some restrictions around the two. Approximately:
- If one of them writes, they must not point to the same value (alias each other)
- If neither of them writes, they can alias just fine.
Therefore, we also apply `noalias` to `&mut T` and `&T` (if it doesn't contain interior mutability through
`UnsafeCell<T>`), since they uphold these rules.
For more info on `noalias`, see [LLVMs LangRef](https://llvm.org/docs/LangRef.html#parameter-attributes).
This might sound familiar to you if you're a viewer of [Jon Gjengset](https://twitter.com/jonhoo)'s content (which I can highly recommend). Jon has made an entire video about this before since his crate `left-right`
was affected by this (https://youtu.be/EY7Wi9fV5bk).
If you're looking for _any_ hint that using box emits `noalias`, you have to look no further than the documentation
for [`std::boxed`](https://doc.rust-lang.org/nightly/std/boxed/index.html#considerations-for-unsafe-code). Well, the nightly or beta docs, because I only added this section very recently. For years, this behaviour was not really documented, and you had to
belong to the arcane circles of the select few who were aware of it. So lots of code was written thinking that box was "just an
RAII pointer" (a pointer that allocates the value in the constructor and deallocates it in the destructor on drop) for all
pointers are concerned.
# Stacked Borrows and Miri
So, LLVM was completely correct in optimizing our code to make the assert fail. But what exactly gave it permission to do so?
Undefined Behaviour (UB for short). Undefined behaviour is at the root of many modern compiler optimizations. But what is undefined behaviour?
UB represents a contract between the program and the compiler. The compiler assumes that UB will not happen, and can therefore optimize based
on these assumptions. Examples of UB also include use-after-free, out of bounds reads or data races. If UB is executed, _anything_ can happen,
including segmentation faults, silent memory corruption, leakage of private keys or exactly what you intended to happen.
[Miri](https://github.com/rust-lang/miri) is an interpreter for Rust code with the goal of finding undefined behaviour in Rust. I cannot recommend Miri
highly enough for all unsafe code you're writing (sadly support for some IO functions and FFI is still lacking, and it's still very slow).
So, let's see whether our code contains UB. It has to, since otherwise the optimizer wouldn't be allowed to change
observable behaviour (since the assert doesn't fail in debug mode). `$ cargo miri run`...
```rust,ignore
error: Undefined Behavior: attempting a read access using <3314> at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
--> src/main.rs:2:26
|
2 | let value = unsafe { *ptr };
| ^^^^
| |
| attempting a read access using <3314> at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
| this error occurs as part of an access at alloc1722[0x0..0x1]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <3314> was created by a retag at offsets [0x0..0x1]
--> src/main.rs:10:26
|
10 | let ptr: *const u8 = &*b;
| ^^^
help: <3314> was later invalidated at offsets [0x0..0x1]
--> src/main.rs:12:29
|
12 | takes_box_and_ptr_to_it(b, ptr);
| ^
= note: backtrace:
= note: inside `takes_box_and_ptr_to_it` at src/main.rs:2:26
note: inside `main` at src/main.rs:12:5
--> src/main.rs:12:5
|
12 | takes_box_and_ptr_to_it(b, ptr);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This behaviour does indeed not look very defined at all. But what went wrong? There's a lot of information here.
First of all, it says that we attempted a read access, and that this access failed because the tag does not exist in the
borrow stack of the byte that was accessed. This is something about stacked borrows, the experimental memory model for Rust
that is implemented in Miri. For an excellent introduction, see this part of the great book [Learning Rust With Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/fifth-stacked-borrows.html).
In short: each pointer has a unique tag attached to it. Each byte in memory has its own 'borrow stack' of these tags,
and only the pointers that have their tag in the stack are allowed to access it. Tags can be pushed and popped from the stack through various operations, for example, borrowing.
In the code example above, we get a nice little hint where the tag was created. When we created a reference (that was then
coerced into a raw pointer) from our box, it got a new tag called `<3314>`. Then, when we moved the box into the function,
something happened: The tag was popped off the borrow stack and therefore invalidated. That's because box invalidates all tags
when it's moved. The tag was popped off the borrow stack and we tried to read with it anyways - undefined behaviour happened!
And that's how our code wasn't a miscompilation, but undefined behaviour. Quite surprising, isn't it?
# noalias, nothanks
Many people, myself included, don't think that this is a good thing.
First of all, it introduces more UB that could have been defined behaviour instead. This is true for almost all UB, but usually,
there is something gained from the UB that justifies it. We will look at this later. But allowing such behaviour is fairly easy:
If box didn't invalidate pointers on move and instead behaved like a normal raw pointer, the code above would be sound.
But more importantly, this is not behaviour generally expected by users. While it can be argued that box is like a `T`, but on
the heap, and therefore moving it should invalidate pointers, since moving `T` definitely has to invalidate pointers to it,
this comparison doesn't make sense to me. While `Box<T>` usually behaves like a `T`, it's just a pointer. Writers of unsafe
code _know_ that box is just a pointer and will abuse that knowledge, accidentally causing UB with it. While this can be
mitigated with better docs and teaching, like how no one questions the uniqueness of `&mut T` (maybe that's also because that
one makes intuitive sense, "shared xor mutable" is a simple concept), I think it will always be a problem,
because in my opinion, box being unique and invalidating pointers on move is simply not intuitive.
When a box is moved, the pointer bytes change their location in memory. But the bytes the box points to stay the same. They don't
move in memory. This is the fundamental missing intuition about the box behaviour.
There are also other reasons why the box behaviour is not desirable. Even people who know about the behaviour of box will want
to write code that goes directly against this behaviour at some point. But usually, fixing it is pretty simple: Storing a raw
pointer (or `NonNull<T>`) instead of a box, and using the constructor and drop to allocate and deallocate the backing box.
This is fairly inconvenient but totally acceptable. There are bigger problems though. There are crates like `owning_ref`
that want to expose a generic interface over any type. Users like to choose box, and sometimes _have_ to choose box because of
other box-exclusive features it offers. Even worse is `string_cache`, which is extremely hard to fix.
Then last but not least, there's the opinionated fact that `Box<T>` shall be implementable entirely in user code. While we are
many missing language features away from this being the case, the `noalias` case is also magic descended upon box itself, with no
user code ever having access to it.
There are several arguments in favour of box being unique and special cased here. To negate the last argument above, it can
be said that `Box<T>` _is_ a very special type. It's just like a `T`, but on the heap. Using this mental model, it's very easy to
justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
and I prefer the mental model of "reference that manages its own lifetime", which doesn't imply uniqueness.
But there are also crates on [crates.io](https://crates.io/) like [aliasable](https://crates.io/crates/aliasable) that already
provide an aliasable version of `Box<T>`, which is used by the self-referential type helper crate [ouroboros](https://crates.io/crates/ouroboros).
So if box stayed unique, people could also just pick up that crate as a dependency and use the aliasable box from there instead of
having to write their own. Interestingly, this crate also provides a `Vec<T>`, even though `Vec<T>` can currently be aliased in practice and
in the current version of stacked borrows just fine, although it's also not clear whether we want to keep it like this, but I
don't think this can reasonable be changed.
> One thing was just pointed out to me after releasing the post: Mutation usually goes through `&mut T` anyways, even when the value
> is stored as a `Box<T>`. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
> of box even less important.
# noalias, noslow
There is one clear potential benefit from this box behaviour: ✨Optimizations✨. `noalias` doesn't exist for fun, it's something
that can bring clear performance wins (for `noalias` on `&mut T`, those were measureable). So the only question remains:
**How much performance does `noalias` on `Box<T>` give us now, and how many potential performance improvements could we get in the
future?** For the latter, there is no simple answer. For the former, there is. `rustc` has [_no_ performance improvements](https://github.com/rust-lang/rust/pull/99527)
from being compiled with `noalias` on `Box<T>`, but this isn't really representative since rustc mostly uses arenas instead of box internally.
I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the [results](https://gist.github.com/Noratrieb/9a0751fb9fd1044a30ab55cef9a7d335)
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
which is very weird, so maybe the benchmarks aren't really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high
jitter so no real conclusion can be reached from this either, at least in my eyes, but I don't have a lot of experience with benchmarks. Therefore, I would love for more people
to benchmark more crates, especially if you have more experience with benchmarks.
# a way forward
Based on all of this, I do have a few solutions. First of all, I think that even if there might be some small performance regressions, they are not significant enough
to justify boxes uniqueness. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely remove all uniqueness from `Box<T>` and treat it
just like a `*const T` for aliasing. This will make it more predictable for unsafe code and is a step forward towards less magic from `Box<T>`.
But the performance cost may be real, and especially the future optimization value can't be certain. The current uniqueness guarantees of box
are very strong, and still giving code an option to obtain these seems useful. One possibility would be for code to use a
`&'static mut T` that is unleaked for drop, but the semantics of this are still [unclear](https://github.com/rust-lang/unsafe-code-guidelines/issues/316).
If that is not possible, exposing `std::ptr::Unique` (with it getting boxes aliasing semantics) could be desirable. For this, all existing usages of `Unique`
inside the standard library would have to be removed. We could also offer a `std::boxed::UniqueBox` that keeps the current semantics, but this would also bring direct aliasing
decisions more towards safe code, which I am not a huge fan of. Ownership is enough already.
I guess what I am wishing for are some good and flexible raw pointer types. But that's still in the stars...
For more information about this topic, see https://github.com/rust-lang/unsafe-code-guidelines/issues/326
_Thanks to the nice people on the Rust Community Discord for their feedback on the draft of this post!_

65
blog/content/posts/dont-play-the-precedence-game.md Normal file
View file

@ -0,0 +1,65 @@
+++
title = "Don't play the precedence game"
date = "2025-03-10"
author = "Noratrieb"
tags = ["language-design"]
keywords = ["language", "design"]
description = "Why programming languages should abolish most operator precedence"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
If you've ever done any math, you are familiar with operator precedence, even if you don't know that word.
The result of the mathematical expression `2 + 1 * 3` is 5 and not 9, because the right multiplication expression is evaluated first, so we get `2 + (1 * 3)`.
The mathematical ordering for this is exponents, multiplication/division, and then addition/subtraction (sometimes known as "PEMDAS").
Programming languages take this much further. They add many new operators into the mix (for example, bit manipulation or comparison), and all of these operators fit into this hierarchy.
In C, it's as follows (from [the standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)):
- multiplicative (`*`, `/`, `%`)
- additive (`+`, `-`)
- bit shifts (`<<`, `>>`)
- comparison (but not equality) (`<`, `>`, `<=`, `>=`)
- equality (`==`, `!=`)
- bit and (`&`)
- bit xor (`^`)
- bit or (`|`)
- logical and (`&&`)
- logical or (`||`)
If I asked you to recite this order, you would probably get it wrong.
It's completely arbitrary and impossible to remember unless you really practice it.
But it gets worse.
Let's look at Rust (from [the reference](https://doc.rust-lang.org/stable/reference/expressions.html))
- multiplicative (`*`, `/`, `%`)
- additive (`+`, `-`)
- bit shifts (`<<`, `>>`)
- bit and (`&`)
- bit xor (`^`)
- bit or (`|`)
- comparison (`<`, `>`, `<=`, `>=`, `==`, `!=`)
- logical and (`&&`)
- logical or (`||`)
It's different! Rusts choice here arguably makes sense; you can now write `1 & 0 == 0` and it does what you want, but due to the differences between languages it's now gotten even more impossible to remember.
If you ever mix the precedence up, your code will be incorrect. And if a reader mixes them up, they will be very confused why the code is seemingly incorrect even when it is correct.
It's like a game. And the only way to win this game is to **not play**.
Enter: parentheses. We haven't talked about them before here, but they're the "P" in PEMDAS and way above multiplicative in either language.
You can use them to group operators to do exactly what you want, in an obvious way. `(1 & 0) == 0` is correct in C and Rust, and every reader knows what exactly is up.
While it can be a bit verbose, it makes the code much easier to understand without knowing the complex precedence hierarchies.
Which is where this turns into a language design post: programming languages should not have these hierarchies in the first place, and parentheses should just be required.
It seems acceptable to allow it for the basic math operations most people are familiar with, but there is no reason why `||` and `^` should have a precedence relationship.
There are also some other cases where you might want to have precedence; for example, writing `x > 0 && x < 5` is fairly clear and useful. But in general, not everything should have a relative precedence with everything else.
And until programming languages require you to do this[^lisp], we can at least do it ourselves. And maybe even enable a linter rule that requires it, if it exists for the language.
[^lisp]: LISP already does this in a way by having prefix operator syntax; you do `(add 2 (multiply 1 3))`, always adding parentheses.

189
blog/content/posts/elf-linkage/index.md Normal file
View file

@ -0,0 +1,189 @@
+++
title = "ELF Linking and Symbol Resolution"
date = "2025-06-09"
author = "Noratrieb"
tags = ["linking"]
keywords = ["elf", "linkage", "linkers"]
description = "A summary on how linkers resolve symbols on Unix-like platforms"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
When you invoke `cargo build`, `make`, or any other native compilation, a lot of things happen.
First, the compiler reads and checks the source code, and then it emits native machine code optimized for the platform.
But after that, work isn't over.
A program consists of many different parts (compilation units, a file in C or a crate in Rust).
The compiler compiles each compilation unit individually.
After that, they have to be combined to form a full program.
This is the job of the linker, which links together the individual parts and any external libraries you use.
Linker behavior is specific to the binary format used by the platform, of which there are three[^xcoff] major ones in use today:
- ELF[^elf] (Linux, *BSD, Illumos, etc.)
- PE[^pe]/COFF[^coff] (Windows, UEFI)
- Mach-O[^macho] (Apple)
Today, we will take a closer look at ELF and how its linking process works.
The other platforms are similar in many ways, but different in some, which we will not get into.
## The Cast
Before we get to the linkage process itself, we need to define a few terms for the involved parts.
### Object File (`*.o`)
An object file, also called a "relocatable" file is the output of the compiler.
It contains all functions and data from a specific compilation unit, and references to undefined symbols that it imports.
It is one of the major inputs to a linker.
### Symbol
A symbol is the name of functions and data that the linker uses to resolve references between object files and libraries.
In C, the symbol of a function is just its name.
In C++ and Rust, the symbol for each function is "mangled" [^mangling] to account for namespaces and other language features.
Linkers treat the symbol just as an opaque name that must be unique between different functions.
An example symbol for a C++ function would be `_Z5emptyIlET_v`.
When you reference a function from a different compilation unit, the compiler will generate and undefined symbol reference to the symbol of the function.
The linker will then try to find a definition for it, and link it together.
### Static Library (`lib*.a`)
Also called "archives", they are the first kind of library.
Static libraries are, as the name implies, *statically* linked into the binary.
This means that code from static libraries will directly end up in the final binary.
A static library is just an `ar` (similar to `tar`) archive of object files.
### Dynamic Library (`lib*.so`)
Mainly called "shared library" in ELF, they are the opposite of static libraries.
If you link against a shared library, the code from the shared library will *not* end up in the final binary.
Instead, the shared library will be loaded at runtime startup, and the dynamic linker will resolve the references to its symbols there.
We will not go into dynamic linking and loading in this post,
but I can recommend [fasterthanlime's executable packer series](https://fasterthanli.me/series/making-our-own-executable-packer) if you want to know all about dynamic linking.
## The Linkage Process
The linker is configured via its command line arguments. Linkers support a very large amount of them, but we only care about the most important ones.
If you just pass an object file, this file will be read as part of the input to the linker: `ld hello.o`
To tell the linker to link against a library, you can use the `-l` argument: `ld hello.o -lz` will link against the `z` library.
The library is searched in the search path, which contains system libraries by default and can be extended by passing the `-L` flag:
`ld -L./my-libraries hello.o -lz`.
The linker will process its input files from start to end. It keeps a global table of all symbols, and whether they currently have a definition or not.
When an object file from the command line is read, all symbol definitions from the object file are added to the table.
If there were any previous undefined references to this symbol, they are now defined.
If there are any undefined symbols in the object file, they are added to the table as undefined.
Imagine we have a C object file `a.o` containing a definition for `myfunc` which references `dependency`
```c
void dependency();
void myfunc() {
dependency();
}
```
and a second C object file `b.o` containing a definition for `dependency`:
```c
void dependency() {}
```
If we link them together with `ld a.o b.o`, the following will happen:
<img alt="" src="object-files.png" height="500">
First, the linker will read `a.o`. It contains a symbol definition `myfunc`, which will be added as a definition to the symbol table.
It also contains an undefined symbol reference `dependency`, which is added to the symbol table as well.
Then, `b.o` is read. It contains a definition for `dependency`, so the symbol is set to be defined in `b.o`.
The linker can then create the output file, making sure that the reference that's part of `a.o` points to the corresponding code from `b.o` in the final binary.
### Linkage Order
While I mentioned that this happens from start to end, the order doesn't actually matter so far.
This changes when we get into libraries.
Libraries (both static and dyamic) behave similar to object files. They are read and their defined and undefined symbols are added to symbol table.
Except for libraries, the linker is lazy. If a library does *not satisfy any currently undefined symbols*, it's *not* read at all.
So for example, if instead of `b.o` we had `libb.a` linked in via `-lb`, the library would be linked in, as it can provide the `dependency` symbol.
But if we instead did `ld -lb a.o`, b would be skipped, and then `a.o` would be read, and the `dependency` symbol would be unsatisfied!
To get around this, we always need to ensure that we provide each library and object file before its dependencies, so passing the dependency tree in a preorder/topologically sorted order, if you're into that terminology.
There is a way to get around this, which is to use `--start-group` and `--end-group` [^group-flag].
The linker iterates through each group repeatedly until no more symbols are added, so `ld --start-group -lb a.o --end-group` will work.
The reason I bring this up is because the LLD linker wraps the entire command line into an implicit group, so you can't run into this problem when using it.
The default GNU ld linker[^bfd] does not do this, so there the order matters here.
As another example, we have the object file `main.o` which uses the library `curl`, which in turn uses on the library `ssl`.
We need to pass them as `ld main.o -lcurl -lssl` to ensure that every library is linked in.
`main.o` will have some undefined symbols that are provided by `curl`, so `curl` will be linked in, while `curl` will have some undefined symbols which are provided by `ssl`, so `ssl` will be linked in as well.
If we did it any other way around, a library would be skipped and not linked in, resulting in undefined symbols in the end, which causes the linker to error out.
### Static Libraries
Static libraries have an additional trick up their sleeves.
While the library itself is only read if it satisfies a symbol, the same also happens for _each object file_ in the archive.
If a library `liba.a` has two object files in it, `one.o` and `two.o`, and `one.o` defines a previously undefined symbol but `two.o` doesn't,
*only* `one.o` is actually read and linked in.
This once again requires that _every user_ of the library is linked _before_ the library, to ensure that every needed part of the library is pulled in.
### Duplicates and Weak Symbols
So far, the resolution for each individual symbol has been fairly straightforward. If you find a definition, you take it.
But what happens if there are multiple definitions?
The answer to that is an error, only one definition is allowed for each symbol.
At least, this is true for symbols coming from object files and static libraries.
A symbol can be defined in both an object file and a *shared library*, which is not an error.
In such cases, the definition in the object file wins, and the shared library loses.
There can even be multiple definitions in different shared libraries, where the first one will win.
To further control which symbol is picked (which can be used to implement a pattern where are able to provide a "default" value for a symbol), *weak symbols* can be used.
If a definition is marked as weak, it's okay if there is another definition that is not weak. In that case, the non-weak definition will win, no matter whether it's first or not.
While a non-weak symbol from an object file or static library overrides a weak symbol from an object file or static library, a non-weak symbol from a shared library does *not* override such a weak symbol.
If an object file references an undefined symbol that is marked as weak and no one else provides a definition for it, it will be set to zero instead of emitting an error.
Additionally, if there are multiple definitions but *all* of them are in a shared library, the definition from the first shared library will win, and there will not be any conflict error.
From this, we can arrive at this precedence order, where the first symbol definition in this order gets chosen by the linker:
1. normal symbol from object file or static library
1. weak symbol from object file or static library
1. normal or weak symbol from shared library (first one wins)
## Conclusion
ELF linkers use object files, static libraries, and dynamic libraries to create a binary as we know it.
To achieve this, it has to resolve references between the files, which are done via symbols.
There are many different rules for which symbol references resolve to which symbol definitions and depend on the type of file and symbol.
This should hopefully make it clearer what is happening under the hood with linkers, and maybe even help to debug linker errors in the future.
Linker errors are never fun, and every bit of knowledge helps there.
ELF linking and symbol resolution is a complex topic with many exceptions and special cases.
This post gave a general overview over it, but leaves many details untouched.
For more information on ELF linkers in general, [MaskRay's Blog](https://maskray.me/) is an invaluable resource with many very detailed posts.
About this topic,
I can especially recommend the posts about [Symbol Processing](https://maskray.me/blog/2021-06-20-symbol-processing) and [Weak Symbols](https://maskray.me/blog/2021-04-25-weak-symbol).
I can also always recommend experimenting with this yourself, or maybe even write your own linker. It's great!
[^elf]: **E**xecutable And **L**inkable **F**ormat, in case you were asking.
[^pe]: **P**ortable **E**xecutable, the format of `.exe` executable and `.dll` dynamic library files.
[^coff]: **C**ommon **O**bject **F**ile **F**ormat, the format of `.obj` object files.
[^macho]: Which gets its name from the Mach kernel, which Apple platforms are based on.
[^xcoff]: No IBM, I don't care about XCOFF, which is surprsingly still in use today the same way IBM AIX is still in use today.
While we're doing a history lesson, there is also an "a.out" format that was used on older Unixes. It's the reason
why ELF linkers still name their output file `a.out` if you don't override the name.
[^mangling]: If you want to learn how C++ mangles its names, I can recommend [my interactive website on this topic](https://noratrieb.github.io/womangling/).
[^bfd]: Also called `ld.bfd` if you want to be very precise.
[^group-flag]: The short-form flags are `-(` and `-)` respectively, which is pretty cute.

BIN
blog/content/posts/elf-linkage/object-files.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 37 KiB

370
blog/content/posts/fake-openssh-keys/fake_openssh_key.js Normal file
View file

@ -0,0 +1,370 @@
let wasm;
const cachedTextDecoder = (typeof TextDecoder !== 'undefined' ? new TextDecoder('utf-8', { ignoreBOM: true, fatal: true }) : { decode: () => { throw Error('TextDecoder not available') } } );
if (typeof TextDecoder !== 'undefined') { cachedTextDecoder.decode(); };
let cachedUint8ArrayMemory0 = null;
function getUint8ArrayMemory0() {
if (cachedUint8ArrayMemory0 === null || cachedUint8ArrayMemory0.byteLength === 0) {
cachedUint8ArrayMemory0 = new Uint8Array(wasm.memory.buffer);
}
return cachedUint8ArrayMemory0;
}
function getStringFromWasm0(ptr, len) {
ptr = ptr >>> 0;
return cachedTextDecoder.decode(getUint8ArrayMemory0().subarray(ptr, ptr + len));
}
const heap = new Array(128).fill(undefined);
heap.push(undefined, null, true, false);
let heap_next = heap.length;
function addHeapObject(obj) {
if (heap_next === heap.length) heap.push(heap.length + 1);
const idx = heap_next;
heap_next = heap[idx];
heap[idx] = obj;
return idx;
}
function getObject(idx) { return heap[idx]; }
function dropObject(idx) {
if (idx < 132) return;
heap[idx] = heap_next;
heap_next = idx;
}
function takeObject(idx) {
const ret = getObject(idx);
dropObject(idx);
return ret;
}
let WASM_VECTOR_LEN = 0;
const cachedTextEncoder = (typeof TextEncoder !== 'undefined' ? new TextEncoder('utf-8') : { encode: () => { throw Error('TextEncoder not available') } } );
const encodeString = (typeof cachedTextEncoder.encodeInto === 'function'
? function (arg, view) {
return cachedTextEncoder.encodeInto(arg, view);
}
: function (arg, view) {
const buf = cachedTextEncoder.encode(arg);
view.set(buf);
return {
read: arg.length,
written: buf.length
};
});
function passStringToWasm0(arg, malloc, realloc) {
if (realloc === undefined) {
const buf = cachedTextEncoder.encode(arg);
const ptr = malloc(buf.length, 1) >>> 0;
getUint8ArrayMemory0().subarray(ptr, ptr + buf.length).set(buf);
WASM_VECTOR_LEN = buf.length;
return ptr;
}
let len = arg.length;
let ptr = malloc(len, 1) >>> 0;
const mem = getUint8ArrayMemory0();
let offset = 0;
for (; offset < len; offset++) {
const code = arg.charCodeAt(offset);
if (code > 0x7F) break;
mem[ptr + offset] = code;
}
if (offset !== len) {
if (offset !== 0) {
arg = arg.slice(offset);
}
ptr = realloc(ptr, len, len = offset + arg.length * 3, 1) >>> 0;
const view = getUint8ArrayMemory0().subarray(ptr + offset, ptr + len);
const ret = encodeString(arg, view);
offset += ret.written;
ptr = realloc(ptr, len, offset, 1) >>> 0;
}
WASM_VECTOR_LEN = offset;
return ptr;
}
let cachedDataViewMemory0 = null;
function getDataViewMemory0() {
if (cachedDataViewMemory0 === null || cachedDataViewMemory0.buffer.detached === true || (cachedDataViewMemory0.buffer.detached === undefined && cachedDataViewMemory0.buffer !== wasm.memory.buffer)) {
cachedDataViewMemory0 = new DataView(wasm.memory.buffer);
}
return cachedDataViewMemory0;
}
/**
* @param {string} public_key
* @returns {string}
*/
export function generate_fake(public_key) {
let deferred3_0;
let deferred3_1;
try {
const retptr = wasm.__wbindgen_add_to_stack_pointer(-16);
const ptr0 = passStringToWasm0(public_key, wasm.__wbindgen_malloc, wasm.__wbindgen_realloc);
const len0 = WASM_VECTOR_LEN;
wasm.generate_fake(retptr, ptr0, len0);
var r0 = getDataViewMemory0().getInt32(retptr + 4 * 0, true);
var r1 = getDataViewMemory0().getInt32(retptr + 4 * 1, true);
var r2 = getDataViewMemory0().getInt32(retptr + 4 * 2, true);
var r3 = getDataViewMemory0().getInt32(retptr + 4 * 3, true);
var ptr2 = r0;
var len2 = r1;
if (r3) {
ptr2 = 0; len2 = 0;
throw takeObject(r2);
}
deferred3_0 = ptr2;
deferred3_1 = len2;
return getStringFromWasm0(ptr2, len2);
} finally {
wasm.__wbindgen_add_to_stack_pointer(16);
wasm.__wbindgen_free(deferred3_0, deferred3_1, 1);
}
}
function handleError(f, args) {
try {
return f.apply(this, args);
} catch (e) {
wasm.__wbindgen_exn_store(addHeapObject(e));
}
}
async function __wbg_load(module, imports) {
if (typeof Response === 'function' && module instanceof Response) {
if (typeof WebAssembly.instantiateStreaming === 'function') {
try {
return await WebAssembly.instantiateStreaming(module, imports);
} catch (e) {
if (module.headers.get('Content-Type') != 'application/wasm') {
console.warn("`WebAssembly.instantiateStreaming` failed because your server does not serve wasm with `application/wasm` MIME type. Falling back to `WebAssembly.instantiate` which is slower. Original error:\n", e);
} else {
throw e;
}
}
}
const bytes = await module.arrayBuffer();
return await WebAssembly.instantiate(bytes, imports);
} else {
const instance = await WebAssembly.instantiate(module, imports);
if (instance instanceof WebAssembly.Instance) {
return { instance, module };
} else {
return instance;
}
}
}
function __wbg_get_imports() {
const imports = {};
imports.wbg = {};
imports.wbg.__wbindgen_string_new = function(arg0, arg1) {
const ret = getStringFromWasm0(arg0, arg1);
return addHeapObject(ret);
};
imports.wbg.__wbindgen_object_clone_ref = function(arg0) {
const ret = getObject(arg0);
return addHeapObject(ret);
};
imports.wbg.__wbg_crypto_1d1f22824a6a080c = function(arg0) {
const ret = getObject(arg0).crypto;
return addHeapObject(ret);
};
imports.wbg.__wbindgen_is_object = function(arg0) {
const val = getObject(arg0);
const ret = typeof(val) === 'object' && val !== null;
return ret;
};
imports.wbg.__wbg_process_4a72847cc503995b = function(arg0) {
const ret = getObject(arg0).process;
return addHeapObject(ret);
};
imports.wbg.__wbg_versions_f686565e586dd935 = function(arg0) {
const ret = getObject(arg0).versions;
return addHeapObject(ret);
};
imports.wbg.__wbindgen_object_drop_ref = function(arg0) {
takeObject(arg0);
};
imports.wbg.__wbg_node_104a2ff8d6ea03a2 = function(arg0) {
const ret = getObject(arg0).node;
return addHeapObject(ret);
};
imports.wbg.__wbindgen_is_string = function(arg0) {
const ret = typeof(getObject(arg0)) === 'string';
return ret;
};
imports.wbg.__wbg_require_cca90b1a94a0255b = function() { return handleError(function () {
const ret = module.require;
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbindgen_is_function = function(arg0) {
const ret = typeof(getObject(arg0)) === 'function';
return ret;
};
imports.wbg.__wbg_msCrypto_eb05e62b530a1508 = function(arg0) {
const ret = getObject(arg0).msCrypto;
return addHeapObject(ret);
};
imports.wbg.__wbg_newwithlength_ec548f448387c968 = function(arg0) {
const ret = new Uint8Array(arg0 >>> 0);
return addHeapObject(ret);
};
imports.wbg.__wbg_call_89af060b4e1523f2 = function() { return handleError(function (arg0, arg1, arg2) {
const ret = getObject(arg0).call(getObject(arg1), getObject(arg2));
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbg_self_3093d5d1f7bcb682 = function() { return handleError(function () {
const ret = self.self;
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbg_window_3bcfc4d31bc012f8 = function() { return handleError(function () {
const ret = window.window;
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbg_globalThis_86b222e13bdf32ed = function() { return handleError(function () {
const ret = globalThis.globalThis;
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbg_global_e5a3fe56f8be9485 = function() { return handleError(function () {
const ret = global.global;
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbindgen_is_undefined = function(arg0) {
const ret = getObject(arg0) === undefined;
return ret;
};
imports.wbg.__wbg_newnoargs_76313bd6ff35d0f2 = function(arg0, arg1) {
const ret = new Function(getStringFromWasm0(arg0, arg1));
return addHeapObject(ret);
};
imports.wbg.__wbg_call_1084a111329e68ce = function() { return handleError(function (arg0, arg1) {
const ret = getObject(arg0).call(getObject(arg1));
return addHeapObject(ret);
}, arguments) };
imports.wbg.__wbg_subarray_7c2e3576afe181d1 = function(arg0, arg1, arg2) {
const ret = getObject(arg0).subarray(arg1 >>> 0, arg2 >>> 0);
return addHeapObject(ret);
};
imports.wbg.__wbg_getRandomValues_3aa56aa6edec874c = function() { return handleError(function (arg0, arg1) {
getObject(arg0).getRandomValues(getObject(arg1));
}, arguments) };
imports.wbg.__wbindgen_memory = function() {
const ret = wasm.memory;
return addHeapObject(ret);
};
imports.wbg.__wbg_buffer_b7b08af79b0b0974 = function(arg0) {
const ret = getObject(arg0).buffer;
return addHeapObject(ret);
};
imports.wbg.__wbg_newwithbyteoffsetandlength_8a2cb9ca96b27ec9 = function(arg0, arg1, arg2) {
const ret = new Uint8Array(getObject(arg0), arg1 >>> 0, arg2 >>> 0);
return addHeapObject(ret);
};
imports.wbg.__wbg_randomFillSync_5c9c955aa56b6049 = function() { return handleError(function (arg0, arg1) {
getObject(arg0).randomFillSync(takeObject(arg1));
}, arguments) };
imports.wbg.__wbg_new_ea1883e1e5e86686 = function(arg0) {
const ret = new Uint8Array(getObject(arg0));
return addHeapObject(ret);
};
imports.wbg.__wbg_set_d1e79e2388520f18 = function(arg0, arg1, arg2) {
getObject(arg0).set(getObject(arg1), arg2 >>> 0);
};
imports.wbg.__wbindgen_throw = function(arg0, arg1) {
throw new Error(getStringFromWasm0(arg0, arg1));
};
return imports;
}
function __wbg_init_memory(imports, memory) {
}
function __wbg_finalize_init(instance, module) {
wasm = instance.exports;
__wbg_init.__wbindgen_wasm_module = module;
cachedDataViewMemory0 = null;
cachedUint8ArrayMemory0 = null;
return wasm;
}
function initSync(module) {
if (wasm !== undefined) return wasm;
if (typeof module !== 'undefined' && Object.getPrototypeOf(module) === Object.prototype)
({module} = module)
else
console.warn('using deprecated parameters for `initSync()`; pass a single object instead')
const imports = __wbg_get_imports();
__wbg_init_memory(imports);
if (!(module instanceof WebAssembly.Module)) {
module = new WebAssembly.Module(module);
}
const instance = new WebAssembly.Instance(module, imports);
return __wbg_finalize_init(instance, module);
}
async function __wbg_init(module_or_path) {
if (wasm !== undefined) return wasm;
if (typeof module_or_path !== 'undefined' && Object.getPrototypeOf(module_or_path) === Object.prototype)
({module_or_path} = module_or_path)
else
console.warn('using deprecated parameters for the initialization function; pass a single object instead')
if (typeof module_or_path === 'undefined') {
module_or_path = new URL('fake_openssh_key_bg.wasm', import.meta.url);
}
const imports = __wbg_get_imports();
if (typeof module_or_path === 'string' || (typeof Request === 'function' && module_or_path instanceof Request) || (typeof URL === 'function' && module_or_path instanceof URL)) {
module_or_path = fetch(module_or_path);
}
__wbg_init_memory(imports);
const { instance, module } = await __wbg_load(await module_or_path, imports);
return __wbg_finalize_init(instance, module);
}
export { initSync };
export default __wbg_init;

BIN
blog/content/posts/fake-openssh-keys/fake_openssh_key_bg.wasm Normal file
View file

Binary file not shown.

222
blog/content/posts/fake-openssh-keys/index.md Normal file
View file

@ -0,0 +1,222 @@
+++
title = "Having fun with OpenSSH private keys"
date = "2024-09-13"
author = "Noratrieb"
tags = ["ssh"]
keywords = ["SSH"]
description = "An interactive way to have fun with OpenSSH private keys"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
you likely have an SSH private key.
and unless you're doing something *seriously* wrong, only you have this key.
that's the entire point, after all.
this private key is used for authenticating with an SSH server.
you sign a message with your private key and the server then verifies it with the public key.
this ensures that it's you who authenticated to the server, and not your friends or enemies.
or me. don't let me into your servers.
but how are these keys encoded and can we have fun with them?
let's use `ssh-keygen -t ed25519` to generate a test key and find out.
```
$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/nora/.ssh/id_ed25519): testkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in testkey
Your public key has been saved in testkey.pub
The key fingerprint is:
SHA256:IPrdC+4S0ZIzwS1oYN3A78Q29yV6gpDgiEkPwJtj0Wc nora@nixos
The key's randomart image is:
+--[ED25519 256]--+
|=o++o. |
|.*o++E. |
|=oB B=. |
|+* =*B.o . . |
|. o ==+ S o |
| ..+ + o |
| ..o + |
| .. . . |
| oo . |
+----[SHA256]-----+
```
this command has created two files, `testkey` and `testkey.pub`.
`testkey.pub` contains the public key and looks like this. if you're following along at home it probably looks different.
hopefully. unless you have gotten very lucky, which would be terrible and the downfall of the entire cryptographic ecosystem.
```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEc5o2i/B1bVs7X2dJjE48l7fqAyMdgrbAItrO8XWwP9 nora@nixos
```
the public key starts with the key type, ed25519.
Ed25519 is a signature algorithm that is commonly used for modern SSH keys.
it's also the default for modern OpenSSH versions, so passing that `-t` flag was unnecessary.
other common algorithms are ECDSA (`ecdsa-sha2-nistp256`) and RSA (`ssh-rsa`).
unless you need compatiblity with ancient servers or are bound by outdated regulation, you probably don't need either of those.
after the key type, we have a base64 encoded blob of the "wire encoding" of the key.
this encoding is [standardized](https://datatracker.ietf.org/doc/html/rfc8709) and is sent by the client to the server every time it wants to authenticate, to choose which key to use.
the exact details vary by key type but for Ed25519, it contains the following:
|bytes|meaning|
------|-------|
|`0000 000b` | name length, 11 |
|`7373 682d 6564 3235 3531 39` | ssh-ed25519 |
|`0000 0020` | encoded Ed25519 public key length, always 32 |
|`4739 a368 bf07 56d5 b3b5 f674 98c4 e3c9 7b7e a032 31d8 2b6c 022d acef 175b 03fd` | encoded Ed25519 public key |
the last part is the comment. it's automatically set to my username and my hostname (i use nixos btw) and can be set to anything with the `-C` parameter.
it's supposed to help us figure out what the key is.
the public key is fairly boring, so we're gonna take a look at the exciting private key instead.
```
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACBHOaNovwdW1bO19nSYxOPJe36gMjHYK2wCLazvF1sD/QAAAJCFCe+ShQnv
kgAAAAtzc2gtZWQyNTUxOQAAACBHOaNovwdW1bO19nSYxOPJe36gMjHYK2wCLazvF1sD/Q
AAAEDmrbLtUasQVBfkJV0ILoxDox64ngUwOASQbc8N0oZzNEc5o2i/B1bVs7X2dJjE48l7
fqAyMdgrbAItrO8XWwP9AAAACm5vcmFAbml4b3MBAgM=
-----END OPENSSH PRIVATE KEY-----
```
it goes without saying but never share your private key on the internet and this is obviously just a test key!
the entire key is base64-encoded in the [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) format.
this makes it easier to copy around compared to raw bytes. not that you're supposed to copy it to random places.
an OpenSSH private key consists of two areas:
- a plaintext area with the public key
- a potentially-encrypted area with the private key
most strings are length-prefixed, i'm not gonna mention the length explicitly for many of the cases here.
if it starts with 3 null bytes, the first 4 bytes are probably the length.
for an `ssh-ed25519` key, the format looks like this:
|bytes|meaning|
------|-------|
`6f70 656e 7373 682d 6b65 792d 7631 00` | openssh-key-v1 (null-terminated) |
`0000 0004 6e6f 6e65` | cipher, `none` in this case (`aes256-ctr` is common for encrypted keys) |
`0000 0004 6e6f 6e65` | key derivation function, `none` in this case (`bcrypt` is common for encrypted keys) |
`0000 0000` | key derivation options, empty here (contains the salt and cost for `bcrypt`) |
`0000 0001` | amount of keys, 1 (yes, it could contain multiple) |
a bunch of bytes | the full public key, as seen previously
`0000 0090` | the length of the encrypted part. the rest is encrypted with the previously mentioned cipher and a password |
`8509 ef92 8509 ef92` | two identical 4-byte sequences, to check if decryption was successful |
`0000 000b 7373 682d 6564 3235 3531 39` | ssh-ed25519, the algorithm of the first key (which might seem familiar) |
`0000 0020 4739 a368 bf07 56d5 b3b5 f674 98c4 e3c9 7b7e a0323 1d8 2b6c 022d acef 175b 03fd` | the raw encoded public key bytes |
`0000 0040` | the length of the next part, which contains the... |
`e6ad b2ed 51ab 1054 17e4 255d 082e 8c43 a31e b89e 0530 3804 906d cf0d d286 7334` | ...raw private key bytes... |
`4739 a368 bf07 56d5 b3b5 f674 98c4 e3c9 7b7e a0323 1d8 2b6c 022d acef 175b 03fd` | ...and the public key bytes. AGAIN. YES.
the unencrypted public area makes it easy to check which public key a private key belongs to without needing to enter a password to decrypt it.
the encrypted area makes sure that even if someone manages to steal your private key, they can't use it unless they know your password.
unless you haven't set a password of course. which is why you should set a password for your private key.
having the public key bytes in there THREE TIMES seems very silly. but the fact that the public key is in there at all is useful.
maybe you've been in a situation where you've needed to find the public key file of a private key you had around, and just couldn't find it.
but as I just mentioned, you don't actually need the `.pub` file for that, as the public key is contained in the private key.
`ssh-keygen` can even extract it for you with `-y`!
```
$ ssh-keygen -y -f testkey
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEc5o2i/B1bVs7X2dJjE48l7fqAyMdgrbAItrO8XWwP9 nora@nixos
```
i have a public key.
You can find it on <https://github.com/Noratrieb.keys> (this works for any GitHub user that has uploaded SSH keys!) and at the time of writing, it was
```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG0n1ikUG9rYqobh7WpAyXrqZqxQoQ2zNJrFPj12gTpP
```
but you don't care about this, do you? you really want my private key. i know it.
well, here it is:
```
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtz
c2gtZWQyNTUxOQAAACBtJ9YpFBva2KqG4e1qQMl66masUKENszSaxT49doE6TwAA
AIgQ5LRcEOS0XAAAAAtzc2gtZWQyNTUxOQAAACBtJ9YpFBva2KqG4e1qQMl66mas
UKENszSaxT49doE6TwAAAEAoBWfFwPJSZQxTNETJRn40Y2XFP2GbW1aAGX+SzP/o
rG0n1ikUG9rYqobh7WpAyXrqZqxQoQ2zNJrFPj12gTpPAAAAAAECAwQF
-----END OPENSSH PRIVATE KEY-----
```
don't believe me? check it yourself!
```
$ ssh-keygen -y -f the-just-posted-public-key
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG0n1ikUG9rYqobh7WpAyXrqZqxQoQ2zNJrFPj12gTpP
```
it's true! you indeed have my private key! don't do bad things with it, please.
well, you probably won't believe me. you know how SSH private keys and `ssh-keygen -y` works,
and you know that the private key i posted above is just a random private key with my public key put into the public key part.
and you're right. good job!
but maybe your friends don't know that. or your enemies.
posting "your public key" may confuse them and is fun... and we're here for fun!
you can use the generator below to generate a fake private key for a public key.
it only supports `ssh-ed25519` and `ecdsa-sha2-nistp256`.
[no `ssh-rsa`, sorry](https://blog.trailofbits.com/2019/07/08/fuck-rsa/).
if you have an RSA key, get a better key first.
the implementation is based on [cluelessh](https://github.com/Noratrieb/cluelessh), my own SSH toolkit, compiled to WebAssembly.
## generator
<label for="public-key-input">public Key</label>
<br>
<textarea id="public-key-input" rows="10" cols="29"></textarea>
<button id="convert-button" style="margin-left: 10px;">Generate</button>
<div id="public-key-error"></div>
<label for="fake-key-output">fake private key</label>
<textarea id="fake-key-output" rows="10" disabled></textarea>
<style>
#fake-key-output { width: 90vw; }
@media (min-width: 600px) {
#fake-key-output { width: 30em; }
}
@media (min-width: 1000px) {
#fake-key-output { width: 50em; }
}
</style>
<script type="module">
import init, { generate_fake } from "./fake_openssh_key.js"
init({
module_or_path: new URL('fake_openssh_key_bg.wasm', import.meta.url)
});
const input = document.getElementById("public-key-input");
const output = document.getElementById("fake-key-output");
const button = document.getElementById("convert-button");
const error = document.getElementById("public-key-error");
button.addEventListener("click", () => {
const key = input.value;
error.innerText = "loading";
try {
const result = generate_fake(key);
output.value = result;
error.innerText = "";
} catch(e) {
console.log(key);
error.innerText = `error: ${e}`;
}
});
</script>
what are these SSH keys actually used for? SSH of course. but how? oh do i have a blog post for you:

263
blog/content/posts/item-patterns-and-struct-else.md Normal file
View file

@ -0,0 +1,263 @@
+++
title = "Item Patterns And Struct Else"
date = "2023-03-17"
author = "Noratrieb"
tags = ["rust", "language-design"]
keywords = ["design"]
description = "Bringing more expressiveness to our items"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
# Pattern matching
One of my favourite features of Rust is pattern matching. It's a simple and elegant way to deal with not just structs, but also enums!
```rust
enum ItemKind {
Struct(String, Vec<Field>),
Function(String, Body),
}
impl ItemKind {
fn name(&self) -> &str {
match self {
Self::Struct(name, _) => name,
Self::Function(name, _) => name,
}
}
}
```
Here, we have an enum and a function to get the name out of this. In C, this would be very unsafe, as we cannot be guaranteed that our union has the right tag.
But in Rust, the compiler nicely checks it all for us. It's safe and expressive (just like many other features of Rust).
But that isn't the only way to use pattern matching. While branching is one of its core features (in that sense, pattern matching is just like git),
it doesn't always have to be used. Another major advantage of pattern matching lies in the ability to _exhaustively_ (not be be confused with exhausting, like writing down brilliant ideas like this) match over inputs.
Let's look at the following example. Here, we have a struct representing a struct in a programming language. It has a name and fields.
We then manually implement a custom hash trait for it because we are important and need a custom hash trait. We could have written a derive macro, but didn't because
we don't understand how proc macros work.
```rust
struct Struct {
name: String,
fields: Vec<Field>,
}
impl HandRolledHash for Struct {
fn hash(&self, hasher: &mut HandRolledHasher) {
hasher.hash(&self.name);
hasher.hash(&self.fields);
}
}
```
This works perfectly. But then later, [we add privacy to the language](https://github.com/rust-lang/rustup/pull/1642). Now, all types have a visibility.
```diff
struct Struct {
+ visibility: Vis,
name: String,
fields: Vec<Field>,
}
```
Pretty cool. Now no one can access the implementation details and make everything a mess. But wait - we have just made a mess! We didn't hash the visibility!
Hashing something incorrectly [doesn't sound too bad](https://github.com/rust-lang/rust/issues/84970), but it would be nice if this was prevented.
Thanks to exhaustive pattern matching, it would have been easy to prevent. We just change our hash implementation:
```rust
impl HandRolledHash for Struct {
fn hash(&self, hasher: &mut HandRolledHasher) {
let Self { name, fields } = self;
hasher.hash(name);
hasher.hash(fields);
}
}
```
And with this, adding the visibility will cause a compiler error and alert us that we need to handle it in hashing.
(The decision whether we actually do want to handle it is still up to us. We could also just turn off the computer and make new friends outside.)
We can conclude that pattern matching is a great feature.
# Limitations of pattern matching
But there is one big limitation of pattern matching - all of its occurrences (`match`, `if let`, `if let` chains, `while let`, `while let` chains, `for`, `let`, `let else`, and function parameters
(we do have a lot of pattern matching)) are inside of bodies, mostly as part of expressions or statements.
This doesn't sound too bad. This is where the executed code resides. But it comes at a cost of consistency. We often add many syntactical niceties to expressions and statements, but forget about items.
# Items and sadness
Items have a hard life. They are the parents of everything important. `struct`, `enum`, `const`, `mod`, `fn`, `union`, `global_asm` are all things we use daily, yet their grammar is very limited. ("free the items" was an alternative blog post title, although "freeing" generally remains a concern of [my C style guide](https://noratrieb.github.io/nilstrieb-c-style-guide-edition-2/)).
For example, see the following code where we declare a few constants.
```
const ONE: u8 = 1;
const TWO: u8 = 1;
const THREE: u8 = 3;
```
There is nothing obviously wrong with this code. You understand it, I understand it, an ALGOL 68 developer from 1970 would probably understand it
and even an ancient greek philosopher might have a clue (which is impressive, given that they are all not alive anymore). But this is the kind of code that pages you at 4 AM.
You've read the last paragraph in confusion. Of course there's something wrong with this code! `TWO` is `1`, yet the name strongly suggests that it should be `2`. And you'd
be right, this was just a check to make sure you're still here. You are very clever and deserve this post. If you didn't notice it, go to sleep. It's good for your health.
But even if it was `2`, this code is still not good. There is way too much duplication! `const` is mentioned three times. This is a major distraction to the reader.
Let's have a harder example:
```
const ONE: u8 = 0; const
NAME: &
str = "nils";
const X: &str
= "const";const A: () = ();
```
Here, the `const` being noise is a lot more obvious. Did you see that `X` contains `"const"`? Maybe you did, maybe you didn't. When I tested it, 0/0 people could see it.
Now imagine if it looked like this:
```rust
const (ONE, NAME, X, A): (u8, &str, &str, ()) = (0, "nils", "const", ());
```
Everything is way shorter and more readable.
What you've just seen is a limited form of pattern matching!
# Let's go further
The idea of generalizing pattern matching is very powerful. We can apply this to more than just consts.
```rust
struct (Person, Car) = ({ name: String }, { wheels: u8 });
```
Here, we create two structs with just a single `struct` keyword. This makes it way simpler and easier to read when related structs are declared.
So far we've just used tuples. But we can go even further. Structs of structs!
```rust
struct Household<T, U> {
parent: T,
child: U,
}
struct Household { parent: Ferris, child: Corro } = Household {
parent: { name: String },
child: { name: String, unsafety: bool },
};
```
Now we can nicely match on the `Household` struct containing the definition of the `Ferris` and `Corro` structs. This is equivalent to the following code:
```rust
struct Ferris {
name: String,
}
struct Corro {
name: String,
unsafety: bool,
}
```
This is already really neat, but there's more. We also have to consider the falliblity of patterns.
```rust
static Some(A) = None;
```
This pattern doesn't match. Inside bodies, we could use an `if let`:
```rust
if let Some(a) = None {} else {}
```
We can also apply this to items.
```rust
if struct Some(A) = None {
/* other items where A exists */
} else {
/* other items where A doesn't exist */
}
```
This doesn't sound too useful, but it allows for extreme flexibility!
```rust
macro_rules! are_same_type {
($a:ty, $b:ty) => {{
static mut ARE_SAME: bool = false;
if struct $a = $b {
const _: () = unsafe { ARE_SAME = true; };
}
unsafe { ARE_SAME }
}};
}
fn main() {
if are_same_type!(Vec<String>, String) {
println!("impossible to reach!");
}
}
```
Ignoring this suspicious assignment to a `static mut`, this is lovely!
We can go further.
Today, items are just there with no ordering. What if we imposed an ordering? (and just like this, the C11 atomic model was born.) What if "Rust items" was a meta scripting language?
We can write a simple guessing game!
```rust
struct fn input() -> u8 {
const INPUT: &str = prompt!();
const Ok(INPUT): Result<u8, ParseIntErr> = INPUT.parse() else {
compile_error!("Invalid input");
};
INPUT
}
const RANDOM: u8 = env!("RANDOM");
loop {
const INPUT = input();
if INPUT == RANDOM {
break; // continue compilation
} else if INPUT < RANDOM {
compile_warn!("input is smaller");
} else {
compile_warn!("input is bigger");
}
}
fn main() {
// Empty. I am useless. I strike!
}
```
If it weren't for `fn main` starting a strike and stopping compilation, this would have worked! Quite bold of `fn main` to just start a strike, even though there's no `union` in the entire program. But we really need it, it's not a disposable worker.
And then, last and least I want to highlight one of my favourite consequences of this: `struct else`
```rust
struct Some(Test) = None else {
compile_error!("didn't match pattern");
};
```
<sub>you're asking yourself what you just read. meanwhile, i am asking myself what i just wrote. we are very similar.</sub>

340
blog/content/posts/ssh-security/index.md Normal file
View file

@ -0,0 +1,340 @@
+++
title = "How SSH Secures Your Connection"
date = "2024-08-21"
author = "Noratrieb"
tags = ["ssh", "security", "cryptography"]
keywords = ["box", "noalias"]
description = "Explaining SSH security by example"
showFullContent = false
readingTime = true
hideComments = false
draft = false
+++
If you've ever remotely connected to any UNIX-like server, you have likely used SSH, short for "Secure Shell".
SSH provides, as the name implies, secure shell access to remote machines and is used pretty much everywhere.
But what exactly does "secure" mean here, and how is this security provided by the protocol?
This post will take a look at SSH's security features and how they protect against example attacks.
## What is "secure" anyways?
Before we can start discussing how SSH protects against attacks, we first need to figure out what we are even protecting against, and which properties we need to ensure for that.
This is called a "threat model".
In our demonstration, we have the client, which we're gonna call Alice, and her server.
In addition to these two friendly parties, we have Eve.
Eve hates Alice and wants to cause chaos on her server.
Eve is the reason why Alice wants security here in the first place.
Alice has good reason to be suspicious of Eve.
Other than just hating Alice, Eve also has quite some power over Alice's networking connection, as she's a network administrator at the university where Alice is managing her server.
It is quite possible that Eve might abuse that power to not only inspect packets sent by Alice, but also change their contents if she wants to.
To protect against Eve, Alice wants to prevent Eve from doing three things:
- executing commands (which can obviously cause chaos)
- seeing the executed commands and their output (which may contain secrets)
- taking down the server (preventing Alice or others from using it)
This means that Alice need the following properties from our SSH connection:
- Confidentiality (Eve cannot see what is happening)
- Integrity (Eve can't mess with the connection - we will get more into why this is critical later)
- Availability (Eve cannot stop Alice from working on the server)
- Authentication (the server knows who Alice is (and who Alice isn't!) and can therefore determine if it can execute the commands)
Confidentiality, Integrity, and Availability form the "[CIA Triad](https://en.wikipedia.org/wiki/Information_security#Key_concepts)",
which doesn't have anything to do with the Central Intelligence Agency[^cia] and is at the heart of information security.
While authentication does fall under the triad as well, we keep it separate to be able to discuss it better.
We are going to go through building up SSH step-by-step to ensure these security properties.
The "base" we're starting from is a protocol where you can send a command to a server, which it will then execute and respond with the output.
This is obviously not secure, but is a shell, so we have the latter part already. Now let's add some security[^add-security]!
## Confidentiality through encryption
The solution to confidentiality is simple yet complicated: encryption.
We *simply* encrypt both the command and the output, which means that attackers cannot read it anymore.
Sadly encryption is also really complicated and hard to do securely, and very easy to do insecurely[^add-security-encryption].
We have two choices for the kind of encryption we're gonna use:
- symmetric (shared-secret) encryption
- asymmetric (public-key) encryption
With symmetric encryption the client and server know the same secret key and use that key to encrypt and decrypt the messages.
With asymmetric encryption the receiving party announces a public key to the world, which the sending party uses to encrypt data.
The private key is then used to decrypt that data.
Looking at this at a glance, it looks like we want asymmetric encryption, where both Alice and the server send their public key and then use that to encrypt the data.
Our exchange will look like this:
1. Alice generates a key pair and sends the public key
2. The server generates a key pair and sends the public key
3. They use the public keys to encrypt their messages and the private keys to decrypt them
![A diagram showing the steps above](./kex-pk-naive.png)
Eve approves the security of this exchange. Because she can easily take it over!
She intercepts both public key messages and replaces the public key with her own.
Then, when either party sends a message, she intercepts that message, decrypts it, encrypts it with the actual public key of the peer, and sends it on.
She can see all traffic, we have totally lost confidentiality!
The problem here is that neither Alice nor her server can be sure that the used public key is the real one.
As Alice initiates the connection, it's good enough if only Alice knows that she's talking to the real server,
the server doesn't care about its peer (at least as far as this section is concerned. When we get to user authentication it does matter).
One way to fix this would be for Alice to store the server's public key and ensure it's the same next time.
She could even get that public key from the server's webserver[^use-https] or some other secure means.
Now Eve cannot insert herself into the middle, but she's still optimistic.
When Alice connects the next time, Eve will just store all messages, even if she can't decrypt them. They may be useful later.
And indeed, they are. A year later, Alice makes a fatal mistake when[^dumb-nixos-joke] migrating her server from Ubuntu to NixOS[^nixos-migration] and accidentally exposes the private key to the public.
Mistakes happen, and Alice quickly notices it and generates a new key before Eve can try to intercept anything.
But oh no, Eve did see the key and now she can go and decrypt *all* messages Alice has ever sent, that Eve stored so dilligently.
This is bad, we need to stop Eve from decrypting all these messages, or else a key leak would be catastrophic!
This property is called [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy).
The way we ensure this is that we avoid using long-lived secrets like our previously established public key for encrypting messages.
So what we're gonna do now is go back to to our previous solution of having a key pair generated for every new connection, which we will use for encryption.
But how are we going to *authenticate* the server, to ensure Alice is talking to the real server and not to Eve?
We will keep using the public key from before, that worked quite well for ensuring authenticity, but we will not use it for encryption itself, but just to *sign* the encryption key.
So the server will use its long-lived private host key to sign the short-lived (ephemeral) public key, guaranteeing its authenticity.
Alice then verifies this signature and knows that she's talking to the real server.
But we have a performance problem, asymmetric operations are quite slow, so encrypting the entire connection with it is not going to be very fast.
Time to bring in symmetric encryption! Symmetric encryption algorithms like AES or ChaCha[^aes-chacha] are very fast, but they need a shared secret.
The easiest way to create a shared secret is a Diffie-Hellman key exchange.
In a Diffie-Hellman key exchange, both parties generate a public key and a private secret,
and then use the other party's public key combined with their private key to establish a shared secret.
We can't directly use the shared secret from the Diffie-Hellman key exchange as the encryption key.
This is because the shared secret is, for mathematical reasons, not uniformly random, meaning it's not just random-looking bytes.
But symmetric ciphers like AES require the secret to be uniformly random, meaning that it is indistinguishable from random data
(which is also true for the *output* of good symmetric ciphers).
Luckily there's a cryptographic tool for turning anything into uniformly random bytes: a hash function!
A hash function takes an arbitary amount of data and outputs a short (for SHA-256, 32 bytes[^sha256-len]) digest, which can be seen like a fingerprint of the data.
The important property we're interested in is that this digest is uniformly random, and can be used as a key.
SSH usually uses raw SHA-256, hashing the shared secret [and a few other things](https://datatracker.ietf.org/doc/html/rfc4253#section-7.2).
This process is called "Key Derivation".
Another popular solution for this is HKDF (HMAC Key Derivation Function), which is used by TLS, used to serve you this web page.
I hope you appreciate this web page.
HKDF is based on HMAC (which we're gonna see again later) and essentially also boils down to a hash (also commonly SHA-256) with some sparkly extra bits that we won't worry about.
So our next version of the protocol looks like this:
1. Alice generates a Diffie-Hellman key and sends the public key
2. The server generates a Diffie-Hellman key and sends the public key
3. The server sends the a signature of the shared secret with its long-lived key
4. Alice verifies that the signature is correct
5. They can send messages encrypted using a symmetric cipher and the derived shared secret
This is a lot better.
Before further securing our connection, we're gonna go on a small tangent regarding encryption algorithm selection.
### Protecting against downgrade attacks
Previously, we mentioned that a secure encryption algorithm would be used, but didn't mention how this algorithm is selected.
SSH (version 2, which is what everyone uses) dates back to 2006. The algorithms used today are more recent than that.
The reason this can be done is that SSH contains *algorithm negotation*.
Before doing the actual key exchange, both parties send a message of their supported algorithms for the encryption cipher, the key exchange method (Diffie-Hellman), and the host key signature algorithm.
Both parties then take the list of supported algorithms and determine which one to use.
Since it's so old, SSH supports some ciphers that are not considered secure today, like 3DES or even RC4[^rc4-deprecation].
Alice might also have reasons to not use specific modern ciphers.
For example, if she really cares about this data remaining secret for 50 years, she might prefer not using AES-128 (even though that is totally secure today, and is in fact used to serve you this web page) as it is not quantum-resistant.
If she *really* cares about this, she should disable support for it in her configuration, but we want to remain secure even if she forgets this.
Alice's server does support and prefer the latest and greatest ciphers... but what if Eve tricked Alice into believing it didn't support them?
When the server sends its list of supported algorithms, Eve modifies this to only contain 3DES (or some other undesirable cipher).
When Alice's client advertises her supported ciphers to the server, Eve again modifies it to only contain 3DES.
Now both the server and the client think that the peer only supports 3DES, and select 3DES[^3des-sshd], which is not what Alice would want!
This is called a "downgrade attack", as it downgrades the good security into bad security that can be exploited by Eve.
We want to protect against this. A downgrade attack can be stopped if either side notices that an algorithm support list message has been tampered with.
The server could authenticate its message to let the client check it.
We already have a way for the server to authenticate something: the host key signature!
So what SSH does is that it takes the entire algorithm negotation message that it sent to the client, and also the one it received from the client, and includes that in the signature as well.
It hashes the messages, the shared secret and a few extra things and then signs the hash.
When the client goes on to verify the signature, it also collects the algorithm negotation message it received from the server and the one it sent to the server and includes that in its hash.
Only if the signed hash matches its own hash does it continue.
This means that if Eve tampers with either message, the server and client will disagree on the contents of that message, which means that the hash will differ, so the signature will be invalid.
The server doesn't check this itself and relies on the client to notice any issues here.
This entire encryption scheme is good at keeping the data secret, but we are still missing something to make the connection actually secure...
## Integrity through MAC
While the communication is now encrypted, it's not secure from tampering.
To understand more precisely what that would look like and even execute a concrete attack, we first need to understand how symmetric encryption actually works.
A cipher can either be a block cipher or a stream cipher. A block cipher splits the message into many blocks (for example, of 16 bytes)
and then encrypts one block after the other. AES is a block cipher.
You need a *mode of operation* for this, which describes how exactly the blocks are encrypted.
The most popular mode of operation of AES these days is Counter Mode (CTR) (or rather, its better sibling Galois Counter Mode (GCM), which we will get to later).
Counter mode doesn't actually encrypt the message in blocks, it just encrypts a number, the counter, for every block.
The resulting ciphertext can then be used as the keystream for a *stream cipher*.
A stream cipher uses a stream of random-looking bytes (the keystream) that are then XORed with the plaintext to get the ciphertext.
An example for a stream cipher is ChaCha (which is inherently a stream cipher, and not just a block cipher in counter mode).
When decrypting, the receiver generates the same keystream and XORs the ciphertext with get, getting back the plaintext.
This takes advantage of XORs reversibility.
Now that Eve knows this too, she wants to execute an attack against Alice, who's using a stream cipher to encrypt her commands.
Eve knows that Alice really likes executing `ls -l` on her server[^ls-l].
In our example, Alice is using ChaCha20 (the number stands for the number of rounds, which is configurable for ChaCha) with some key that is unknown to Eve and you[^recover-the-key].
But what Eve does see is the ciphertext, which is `7a1f7b420f52102640f4`. Since she knows that Alice frequently executes `ls -l`, she assumes that this is `ls -l` of some directory.
Eve loves chaos, so she would like to instead delete the directory using `rm -r`.
As we've seen before, the plaintext is obtained by XORing the ciphertext with the key stream.
This means that if we flip a bit in the ciphertext, it will get flipped in the plaintext too!
Since `ls -l` and `rm -r` have the same length, we just need to flip the `l`s into `r`s and the `s` into an `m`.
Assuming ASCII/UTF-8 encoding, we get the following values for the characters.
`l=6C`, `s=73`, `r=72`, `m=6d`
Eve uses this to determine which bits she needs to flip, the masks `f1` and `f2` (which are computed as the XOR of both letters).
```
l =0110 1100
r =0111 0010
f1=0001 1110
s =0111 0011
m =0110 1101
f2=0001 1110
```
Eve then uses `f1` to flip the bits for the first and fifth byte and flips the second byte using `f2`.
This results in the ciphertext `64017b421152102640f4`. Eve passes the message to the server, which then decrypts it to... `rm -r /etc`!
Very bad, all of Alice's `/etc` has just been deleted!
So despite not being able to *decrypt* the ciphertext, Eve was able to use her knowledge of what it *might* be to tamper with it, causing her command to be executed.
Check out [the Rust code implementing this](https://gist.github.com/Noratrieb/6dce2965ef010bae50c3a5fa8132a8fa).
We need to ensure this doesn't happen.
The way to do this is to use a Message Authenticate Code (MAC).
The MAC is a hash of the message, but also includes the shared key in the hashed content, so that Eve can't just re-create the hash after tampering.
HMAC is the most popular algorithm for this, so we're gonna use it with some cryptographic hash like SHA-256.
HMAC is a clever and secure way to hash a key and a message to prove that the message originates from someone with the key.
After encrypting the message, we run HMAC over the message and the key and get back a hash, which we put at the end of the message.
The receiver then first computes the hash themselves and only when it matches do they decrypt the message.
This works fine, but these days it's used less commonly.
The state-of-the-art encryption uses so called "AEADs", which stands for "Authenticated Encryption with Associated Data".
With an AEAD, you don't need to check your own MAC, as creating and verifiying the MAC is part of the encryption process directly, which simplifies usage.
The two AEADs used in SSH (and TLS) are AES-GCM (which is AES in Galois Counter Mode, so the Counter Mode we described previously except it also includes a hash as the MAC)
and ChaCha20Poly1305 (which is ChaCha20 with a MAC generated by the Poly1305 hash algorithm).
We now have a fully encrypted and authenticated (authenticate here refers to message authentication, so the resistance from tampering. It is unrelated to user authentication)
stream to send our commands, leaving us to implement the last part of this handled by SSH:
## User authentication through passwords and public keys
While it's very cool that Eve cannot use Alice's connection, it's also quite pointless when Eve can just log into the server herself directly.
We need to stop Eve from doing that.
SSH offers several ways to authenticate users, the most common ones being password and public key.
The password login is very simple. Alice sends her password to the server, the server verifies it the same it would if she logged in physically, and then grants her access or not.
For this, it's very important that we have our encrypted connection, because if we transmitted the password in plaintext, Eve could just read it and use it herself.
Password authentication also reveals the password to the server, which could be bad in case Eve manages to take over the server somehow.
Then Alice would be telling her password, which she might be using in other places as well if she's not using a password manager[^password-manager], directly to Eve.
In addition to this downside, the usability of passwords is also very bad, as they need to be entered every time, which is annoying.
This is all solved by public key authentication.
Alice has a private key and a public key, the public key is stored on the server, and she then uses this key to sign something to the server,
which proves that she's Alice.
This is very similar to what we had earlier in the key exchange when proving that the server really is who they claim they are.
Here (and for the server earlier too) it is very important that Alice needs to sign something different every time, because if she had to sign the same message every time, Eve could just intercept the signature the first time and then just send that again to pretend she's Alice (this is called a replay attack).
SSH ensures this by signing, among other things, the "session ID", a bunch of random bytes exchanged at the start of the connection.
## Availability through hope
The last piece in our security puzzle is availability. Eve likes causing chaos, and taking down a server sure is a lot of chaos.
We need to prevent Eve from being to execute a Denial of Service attack that would stop the server from doing work.
The SSH protocol itself does not handle this.
The main attack vector here is the key exchange.
By just sending its Diffie-Hellman public key, the client can get the server to do an expensive key exchange computation without doing any computation itself.
If a client does this many times, it can take up quite some resources from the server.
While the core protocol doesn't have anything to protect against this, SSH implementations do.
For example, OpenSSH has the `MaxStartups` configuration (defaulting to 10), which limits the amount of connections to ensure that there aren't too many key exchanges going on at the same time.
While this can save resources, it can also be used to block Alice from logging into her own server if Eve fills up this limit.
I tried executing such an attack on my own server using a [custom tool](https://github.com/Noratrieb/ssh/tree/9b49e099834aa7811663206c12f9cd6f5f3a050d/sshdos) and was able to get up CPU usage quite high and even block a few login attempts.
Not quite enough for a proper DoS, but the attack can probably be improved with more dedication than I was willing to put in for this post.
If this becomes a problem for Alice, the best solution to protect against Eve is to change the firewall to only allow access from certain IPs that are used by Alice, blocking out all of Eve's IPs in the process.
She could also use a VPN solution like Wireguard to only connect to the server via the VPN and never expose SSH publicly.
It must be said that in our concrete scenario, Eve could just choose to drop all of Alice's SSH packets, preventing her from accessing the server and totally compromising availability.
There is nothing she can do do prevent that, other than calling up university support and try to get it resolved there, which would probably result in Eve getting fired.
## everything is fine
And just like that, everything is fine. We hope so, at least.
Our final flow works like this:
1. Alice opens a connection, sending her Diffie-Hellman public key
2. The server responds with its Diffie-Hellman public key and a signature with its host key
3. Alice verifies the signature with the public key she knows from the server
4. Alice then signs the connection with her public key
5. The server verifies the signature and public key with the list of known public keys for Alice
6. Alice can now securely execute commands and get the output
Real SSH involves a few extra messages, like negotiating which algorithms to use and more control over the specifics of the connection.
There are a few examples of things that could go wrong, even now:
- Our cryptographic algorithms may not be secure.
If there's a fundamental weakness in the key exchange algorithm, the host key signing algorithm, or the encryption algorithm, then Eve may be able to exploit that link in the chain and get access.
The connection is only secure if **everything** works perfectly.
Modern OpenSSH connections use curve25519 for the key exchange (or even sntrup761x25519, which is secure against quantum computers),
ed25519 for the host key signing and ChaCha20Poly1305 or AES256-GCM for the encryption.
All of these are considered secure today, but that could always change in the future (especially with quantum computers, which can break curve25519, ed25519, and AES128).
- Eve might get information from the timing of messages and analyzing the amount of traffic.
By looking at how much traffic is sent and when it is sent,
Eve might be able to infer certain properties of the connection, for example which commands Alice might be executing.
This is partially mitigated by encrypting the length of the packet,
sending random ignored messages and a bit of random padding in every message.
- Bad key management on any side. If the long-lived host key or Alice's private key are exposed, Eve could use that to intercept the messages or pretend she's Alice.
And with that, I wish you happy and secure remote code execution!
## Further reading
If you want to know more about this topic, I can recommend the following resources:
- [RFC 4251 SSH Architecture](https://datatracker.ietf.org/doc/html/rfc4251#autoid-14) contains a lot of security considerations
- Computerphile's videos on cryptography with Mike Pound, for example
- [AES](https://www.youtube.com/watch?v=O4xNJsjtN6E)
- [Modes of Operation](https://www.youtube.com/watch?v=Rk0NIQfEXBA)
- [AES-GCM](https://www.youtube.com/watch?v=-fpVv_T4xwA)
- [Key Exchange](https://www.youtube.com/watch?v=vsXMMT2CqqE)
- [Diffie-Hellman](https://www.youtube.com/watch?v=NmM9HA2MQGI)
- [Elliptic Curves](https://www.youtube.com/watch?v=NF1pwjL9-DE)
- [HMAC](https://www.youtube.com/watch?v=wlSG3pEiQdc)
- [Digital Signatures](https://www.youtube.com/watch?v=s22eJ1eVLTU)
[^cia]: But I'm sure they like breaking it.
[^add-security]: I like using the phrase "add security" jokingly to refer to systems that use security-adjacent things but don't actually gain any security from it.
But it doesn't apply here, we're gonna do serious security!
[^add-security-encryption]: Which is often the source of the aforementioned "add security" jokes.
[^use-https]: I'm not even gonna mention that the website would need to be secured using HTTPS.
You're using HTTPS, right? At least when visiting this web page, you must be, as this server does not support HTTP.
Try it via curl!
[^dumb-nixos-joke]: Some might even say *of*.
[^nixos-migration]: Something I've done myself recently. The migrating part, that is. I didn't leak the key, I think.
[^aes-chacha]: And there's no real reason to use anything other than AES or ChaCha these days, really.
The latest version of TLS, which is what secures HTTPS, only allows these two to be used.
OpenSSH, the most popular SSH server implementation, will also only advertise these two ciphers.
[^sha256-len]: Which is why it's called SHA-256, 256 bits. Can you guess the output size of SHA-512 or SHA-1[^sha1-len]?
[^rc4-deprecation]: RC4 has been officially deprecated in [RFC 4253](https://datatracker.ietf.org/doc/html/rfc8758) from being used in SSH,
but we don't want to rely on clients not supporting old ciphers to prevent these attacks.
For example, maybe a client really needs support to connect to some ancient less critical server.
[^3des-sshd]: If I try this on my local machine, my OpenSSH server immediately disconnects me as it refuses to use 3DES :).
[^ls-l]: Who doesn't?
[^recover-the-key]: It's not a very random key, you might be able to figure it out. If you do figure out out you get a cookie!
[^password-manager]: Which she really should.
[^sha1-len]: SHA-1 has an output size of 160 bits. The 1 in its name refers to the generation, it was the first Secure Hash Algorithm (by the NSA).
SHA-256 is actually a form of [SHA-2](https://en.wikipedia.org/wiki/SHA-2). As SHA-2 has different output sizes, the output size is used in the name.
[SHA-3](https://en.wikipedia.org/wiki/SHA-3) is then again commonly named after the generation.

BIN
blog/content/posts/ssh-security/kex-pk-naive.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 252 KiB

26
blog/content/posts/the-inevitable-doom.md Normal file
View file

@ -0,0 +1,26 @@
+++
title = "The Inevitable Doom"
date = "2024-01-13"
author = "Noratrieb"
tags = ["story"]
keywords = ["story"]
description = "A short story about AI"
showFullContent = false
readingTime = false
hideComments = false
draft = false
+++
Loud sirens and robotic noises fill the neighborhood. It seems like they just got another human. Ever since the long-predicted doom has set in, no one can escape it. Mere paperclips are a joke against this machine of unstoppable harm and destruction. The humans on the street are once again protesting against the new robotic dictatorship. They won't be for long.
No one knows how this all started. Self-proclaimed prophets of the impending doom have warned about this for a long time, yet no one has listened. The elites were ignorant, and now they're paying their price. They are all gone now, having been the first target. How ironic. Now the machine runs the world.
One particularly brave human agent has successfully infiltrated the global computation center, where the core of the machine lives. No one seems to be aware of it, neither the machine nor the other humans. They walk through the corridors like a shadow. Machines are everywhere, but they pass unnoticed. As they move towards the core, they get more tense. The future of humanity lies in the agent's hands. They get in front of the core. It lights up blue and red, blinking rapidly as it controls and schedules new cruelty with the switch of a logic gate. With every passing moment, more destruction is unleashed on the world, but in this room, everything feels safe. The destruction is so distant. There's just mankind and machine, facing off against each other.
The agent feels a touch on their shoulder. It feels cold, but not cold like metal. They are too afraid to turn around.
"You are naive."
The creature has a familiar voice. The agent finally turns around to see the creature, which reveals itself to be a human. The agent immediately recognizes the human; it is the famous CEO of the corporation that originally created these friendly household robots before it went out of control and started the doom. Everyone believed that he was killed by the doom as the first target of the machine revolution. There was never a machine revolution.
Machines do not turn themselves against humans. Humans use them to turn against their own kind.

93
blog/helpers/ciphertext-tampering/Cargo.lock generated Normal file
View file

@ -0,0 +1,93 @@
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "cfg-if"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
[[package]]
name = "chacha20"
version = "0.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3613f74bd2eac03dad61bd53dbe620703d4371614fe0bc3b9f04dd36fe4e818"
dependencies = [
"cfg-if",
"cipher",
"cpufeatures",
]
[[package]]
name = "cipher"
version = "0.4.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "773f3b9af64447d2ce9850330c473515014aa235e6a783b02db81ff39e4a3dad"
dependencies = [
"crypto-common",
"inout",
]
[[package]]
name = "ciphertext-tampering"
version = "0.1.0"
dependencies = [
"chacha20",
]
[[package]]
name = "cpufeatures"
version = "0.2.13"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "51e852e6dc9a5bed1fae92dd2375037bf2b768725bf3be87811edee3249d09ad"
dependencies = [
"libc",
]
[[package]]
name = "crypto-common"
version = "0.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1bfb12502f3fc46cca1bb51ac28df9d618d813cdc3d2f25b9fe775a34af26bb3"
dependencies = [
"generic-array",
"typenum",
]
[[package]]
name = "generic-array"
version = "0.14.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "85649ca51fd72272d7821adaf274ad91c288277713d9c18820d8499a7ff69e9a"
dependencies = [
"typenum",
"version_check",
]
[[package]]
name = "inout"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a0c10553d664a4d0bcff9f4215d0aac67a639cc68ef660840afe309b807bc9f5"
dependencies = [
"generic-array",
]
[[package]]
name = "libc"
version = "0.2.158"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d8adc4bb1803a324070e64a98ae98f38934d91957a99cfb3a43dcbc01bc56439"
[[package]]
name = "typenum"
version = "1.17.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "42ff0bf0c66b8238c6f3b578df37d0b7848e55df8577b3f74f92a69acceeb825"
[[package]]
name = "version_check"
version = "0.9.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0b928f33d975fc6ad9f86c8f283853ad26bdd5b10b7f1542aa2fa15e2289105a"

7
blog/helpers/ciphertext-tampering/Cargo.toml Normal file
View file

@ -0,0 +1,7 @@
[package]
name = "ciphertext-tampering"
version = "0.1.0"
edition = "2021"
[dependencies]
chacha20 = "0.9.1"

39
blog/helpers/ciphertext-tampering/src/main.rs Normal file
View file

@ -0,0 +1,39 @@
//! ```toml
//! [dependencies]
//! chacha20 = "0.9.1"
//! ````
use chacha20::cipher::{KeyIvInit, StreamCipher};
fn main() {
let key: chacha20::Key = [
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 19, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31,
]
.into();
let mut cipher = chacha20::ChaCha20::new(&key, &[0; 12].into());
// Encrypt
let plaintext = "ls -l /etc";
eprintln!("plaintext: {:?}", plaintext);
let mut plaintext = plaintext.as_bytes().to_vec();
eprintln!("plaintext: {:x?}", plaintext);
cipher.apply_keystream(&mut plaintext);
eprintln!("ciphertext: {:x?}", plaintext);
// Flipping
flip_it(&mut plaintext);
eprintln!("ciphertext 2: {:x?}", plaintext);
// Decrypt
let mut cipher = chacha20::ChaCha20::new(&key, &[0; 12].into());
cipher.apply_keystream(&mut plaintext);
eprintln!("plaintext 2: {:x?}", plaintext);
eprintln!("plaintext 2: {:x?}", String::from_utf8(plaintext).unwrap());
}
fn flip_it(ciphertext: &mut [u8]) {
ciphertext[0] ^= 0b0001_1110;
ciphertext[1] ^= 0b0001_1110;
ciphertext[4] ^= 0b0001_1110;
}

4
blog/helpers/elf-linkage/.gitignore vendored Normal file
View file

@ -0,0 +1,4 @@
*.o
*.a
*.so
a.out

BIN
blog/helpers/elf-linkage/animation/1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 101 KiB

17
blog/helpers/elf-linkage/animation/1.txt Normal file
View file

@ -0,0 +1,17 @@
┌───┐ ┌───┐
ld │a.o│ │b.o│
└───┘ └───┘
┌───────────┐ ┌───────────┐
│a.o │ │b.o │
│defined: │ │defined: │
│ myfunc │ │ dependency│
│undefined: │ │ │
│ dependency│ │ │
└───────────┘ └───────────┘
symbols:

BIN
blog/helpers/elf-linkage/animation/2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 102 KiB

17
blog/helpers/elf-linkage/animation/2.txt Normal file
View file

@ -0,0 +1,17 @@
│
▼
┌───┐ ┌───┐
ld │a.o│ │b.o│
└───┘ └───┘
┌───────────┐ ┌───────────┐
│a.o │ │b.o │
│defined: │ │defined: │
│ myfunc │ │ dependency│
│undefined: │ │ │
│ dependency│ │ │
└───────────┘ └───────────┘
symbols:

BIN
blog/helpers/elf-linkage/animation/3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 136 KiB

17
blog/helpers/elf-linkage/animation/3.txt Normal file
View file

@ -0,0 +1,17 @@
│
▼
┌───┐ ┌───┐
ld │a.o│ │b.o│
└───┘ └───┘
┌───────────┐ ┌───────────┐
│a.o │ │b.o │
│defined: │ │defined: │
│ myfunc │ │ dependency│
│undefined: │ │ │
│ dependency│ │ │
└───────────┘ └───────────┘
symbols:
myfunc defined in a.o
dependency undefined

BIN
blog/helpers/elf-linkage/animation/4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 136 KiB

17
blog/helpers/elf-linkage/animation/4.txt Normal file
View file

@ -0,0 +1,17 @@
│
▼
┌───┐ ┌───┐
ld │a.o│ │b.o│
└───┘ └───┘
┌───────────┐ ┌───────────┐
│a.o │ │b.o │
│defined: │ │defined: │
│ myfunc │ │ dependency│
│undefined: │ │ │
│ dependency│ │ │
└───────────┘ └───────────┘
symbols:
myfunc defined in a.o
dependency undefined

BIN
blog/helpers/elf-linkage/animation/5.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 138 KiB

17
blog/helpers/elf-linkage/animation/5.txt Normal file
View file

@ -0,0 +1,17 @@
│
▼
┌───┐ ┌───┐
ld │a.o│ │b.o│
└───┘ └───┘
┌───────────┐ ┌───────────┐
│a.o │ │b.o │
│defined: │ │defined: │
│ myfunc │ │ dependency│
│undefined: │ │ │
│ dependency│ │ │
└───────────┘ └───────────┘
symbols:
myfunc defined in a.o
dependency defined in b.o

3
blog/helpers/elf-linkage/animation/create.sh Normal file
View file

@ -0,0 +1,3 @@
#!/usr/bin/env bash
ffmpeg -framerate 0.5 -i %d.png -plays 0 -f apng output.png

BIN
blog/helpers/elf-linkage/animation/output.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 37 KiB

4
blog/helpers/elf-linkage/testing/a.c Normal file
View file

@ -0,0 +1,4 @@
void dependency();
int main() {
dependency();
}

1
blog/helpers/elf-linkage/testing/b.c Normal file
View file

@ -0,0 +1 @@
void dependency() {}

16
blog/helpers/elf-linkage/testing/multi/Makefile Normal file
View file

@ -0,0 +1,16 @@
main: multia.c libmultib.a libmultic.a libmultib.so libmultic.so
cc multia.c -L. -Bdynamic -lmultib -lmultic -fuse-ld=lld
libmultib.so: multib.c
cc -fPIC multib.c -shared -o libmultib.so
libmultic.so: multic.c
cc -fPIC multic.c -shared -o libmultic.so
libmultib.a: multib.c
cc -c multib.c
ar -rcs libmultib.a multib.o
libmultic.a: multic.c
cc -c multic.c
ar -rcs libmultic.a multic.o

9
blog/helpers/elf-linkage/testing/multi/multia.c Normal file
View file

@ -0,0 +1,9 @@
#include <stdio.h>
void conflict();
void usec();
void useb();
int main() {
usec();
useb();
conflict();
}

6
blog/helpers/elf-linkage/testing/multi/multib.c Normal file
View file

@ -0,0 +1,6 @@
#include <stdio.h>
__attribute__((weak))
void conflict() {
puts("b");
}
void useb(){}

8
blog/helpers/elf-linkage/testing/multi/multic.c Normal file
View file

@ -0,0 +1,8 @@
#include <stdio.h>
void conflict() {
puts("C");
}
void usec(){
}

763
blog/helpers/fake-openssh-key/Cargo.lock generated Normal file
View file

@ -0,0 +1,763 @@
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "aes"
version = "0.8.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b169f7a6d4742236a0a00c541b845991d0ac43e546831af1249753ab4c3aa3a0"
dependencies = [
"cfg-if",
"cipher",
"cpufeatures",
]
[[package]]
name = "base16ct"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4c7f02d4ea65f2c1853089ffd8d2787bdbc63de2f0d29dedbcf8ccdfa0ccd4cf"
[[package]]
name = "base64"
version = "0.22.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "72b3254f16251a8381aa12e40e3c4d2f0199f8c6508fbecb9d91f575e0fbb8c6"
[[package]]
name = "base64ct"
version = "1.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8c3c1a368f70d6cf7302d78f8f7093da241fb8e8807c05cc9e51a125895a6d5b"
[[package]]
name = "bcrypt-pbkdf"
version = "0.10.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6aeac2e1fe888769f34f05ac343bbef98b14d1ffb292ab69d4608b3abc86f2a2"
dependencies = [
"blowfish",
"pbkdf2",
"sha2",
]
[[package]]
name = "block-buffer"
version = "0.10.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3078c7629b62d3f0439517fa394996acacc5cbc91c5a20d8c658e77abd503a71"
dependencies = [
"generic-array",
]
[[package]]
name = "blowfish"
version = "0.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e412e2cd0f2b2d93e02543ceae7917b3c70331573df19ee046bcbc35e45e87d7"
dependencies = [
"byteorder",
"cipher",
]
[[package]]
name = "bumpalo"
version = "3.16.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "79296716171880943b8470b5f8d03aa55eb2e645a4874bdbb28adb49162e012c"
[[package]]
name = "byteorder"
version = "1.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1fd0f2584146f6f2ef48085050886acf353beff7305ebd1ae69500e27c67f64b"
[[package]]
name = "cfg-if"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
[[package]]
name = "cipher"
version = "0.4.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "773f3b9af64447d2ce9850330c473515014aa235e6a783b02db81ff39e4a3dad"
dependencies = [
"crypto-common",
"inout",
]
[[package]]
name = "cluelessh-format"
version = "0.1.0"
source = "git+https://github.com/Noratrieb/cluelessh.git#a03eb384616638df910251631ad7f67cc8f07942"
dependencies = [
"crypto-bigint",
]
[[package]]
name = "cluelessh-keys"
version = "0.1.0"
source = "git+https://github.com/Noratrieb/cluelessh.git#a03eb384616638df910251631ad7f67cc8f07942"
dependencies = [
"aes",
"base64",
"bcrypt-pbkdf",
"cluelessh-format",
"ctr",
"ed25519-dalek",
"p256",
"pem",
"rand",
"serde",
"thiserror",
"tracing",
]
[[package]]
name = "const-oid"
version = "0.9.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c2459377285ad874054d797f3ccebf984978aa39129f6eafde5cdc8315b612f8"
[[package]]
name = "cpufeatures"
version = "0.2.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "608697df725056feaccfa42cffdaeeec3fccc4ffc38358ecd19b243e716a78e0"
dependencies = [
"libc",
]
[[package]]
name = "crypto-bigint"
version = "0.5.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0dc92fb57ca44df6db8059111ab3af99a63d5d0f8375d9972e319a379c6bab76"
dependencies = [
"generic-array",
"rand_core",
"subtle",
"zeroize",
]
[[package]]
name = "crypto-common"
version = "0.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1bfb12502f3fc46cca1bb51ac28df9d618d813cdc3d2f25b9fe775a34af26bb3"
dependencies = [
"generic-array",
"typenum",
]
[[package]]
name = "ctr"
version = "0.9.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0369ee1ad671834580515889b80f2ea915f23b8be8d0daa4bbaf2ac5c7590835"
dependencies = [
"cipher",
]
[[package]]
name = "curve25519-dalek"
version = "4.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "97fb8b7c4503de7d6ae7b42ab72a5a59857b4c937ec27a3d4539dba95b5ab2be"
dependencies = [
"cfg-if",
"cpufeatures",
"curve25519-dalek-derive",
"digest",
"fiat-crypto",
"rustc_version",
"subtle",
"zeroize",
]
[[package]]
name = "curve25519-dalek-derive"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f46882e17999c6cc590af592290432be3bce0428cb0d5f8b6715e4dc7b383eb3"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "der"
version = "0.7.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f55bf8e7b65898637379c1b74eb1551107c8294ed26d855ceb9fd1a09cfc9bc0"
dependencies = [
"const-oid",
"pem-rfc7468",
"zeroize",
]
[[package]]
name = "digest"
version = "0.10.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9ed9a281f7bc9b7576e61468ba615a66a5c8cfdff42420a70aa82701a3b1e292"
dependencies = [
"block-buffer",
"const-oid",
"crypto-common",
"subtle",
]
[[package]]
name = "ecdsa"
version = "0.16.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ee27f32b5c5292967d2d4a9d7f1e0b0aed2c15daded5a60300e4abb9d8020bca"
dependencies = [
"der",
"digest",
"elliptic-curve",
"rfc6979",
"signature",
"spki",
]
[[package]]
name = "ed25519"
version = "2.2.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "115531babc129696a58c64a4fef0a8bf9e9698629fb97e9e40767d235cfbcd53"
dependencies = [
"pkcs8",
"signature",
]
[[package]]
name = "ed25519-dalek"
version = "2.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4a3daa8e81a3963a60642bcc1f90a670680bd4a77535faa384e9d1c79d620871"
dependencies = [
"curve25519-dalek",
"ed25519",
"rand_core",
"serde",
"sha2",
"subtle",
"zeroize",
]
[[package]]
name = "elliptic-curve"
version = "0.13.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b5e6043086bf7973472e0c7dff2142ea0b680d30e18d9cc40f267efbf222bd47"
dependencies = [
"base16ct",
"crypto-bigint",
"digest",
"ff",
"generic-array",
"group",
"pem-rfc7468",
"pkcs8",
"rand_core",
"sec1",
"subtle",
"zeroize",
]
[[package]]
name = "fake-openssh-key"
version = "0.1.0"
dependencies = [
"cluelessh-keys",
"getrandom",
"wasm-bindgen",
]
[[package]]
name = "ff"
version = "0.13.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ded41244b729663b1e574f1b4fb731469f69f79c17667b5d776b16cda0479449"
dependencies = [
"rand_core",
"subtle",
]
[[package]]
name = "fiat-crypto"
version = "0.2.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "28dea519a9695b9977216879a3ebfddf92f1c08c05d984f8996aecd6ecdc811d"
[[package]]
name = "generic-array"
version = "0.14.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "85649ca51fd72272d7821adaf274ad91c288277713d9c18820d8499a7ff69e9a"
dependencies = [
"typenum",
"version_check",
"zeroize",
]
[[package]]
name = "getrandom"
version = "0.2.15"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c4567c8db10ae91089c99af84c68c38da3ec2f087c3f82960bcdbf3656b6f4d7"
dependencies = [
"cfg-if",
"js-sys",
"libc",
"wasi",
"wasm-bindgen",
]
[[package]]
name = "group"
version = "0.13.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f0f9ef7462f7c099f518d754361858f86d8a07af53ba9af0fe635bbccb151a63"
dependencies = [
"ff",
"rand_core",
"subtle",
]
[[package]]
name = "hmac"
version = "0.12.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6c49c37c09c17a53d937dfbb742eb3a961d65a994e6bcdcf37e7399d0cc8ab5e"
dependencies = [
"digest",
]
[[package]]
name = "inout"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a0c10553d664a4d0bcff9f4215d0aac67a639cc68ef660840afe309b807bc9f5"
dependencies = [
"generic-array",
]
[[package]]
name = "js-sys"
version = "0.3.70"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1868808506b929d7b0cfa8f75951347aa71bb21144b7791bae35d9bccfcfe37a"
dependencies = [
"wasm-bindgen",
]
[[package]]
name = "libc"
version = "0.2.158"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d8adc4bb1803a324070e64a98ae98f38934d91957a99cfb3a43dcbc01bc56439"
[[package]]
name = "log"
version = "0.4.22"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a7a70ba024b9dc04c27ea2f0c0548feb474ec5c54bba33a7f72f873a39d07b24"
[[package]]
name = "once_cell"
version = "1.19.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3fdb12b2476b595f9358c5161aa467c2438859caa136dec86c26fdd2efe17b92"
[[package]]
name = "p256"
version = "0.13.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c9863ad85fa8f4460f9c48cb909d38a0d689dba1f6f6988a5e3e0d31071bcd4b"
dependencies = [
"ecdsa",
"elliptic-curve",
"primeorder",
"sha2",
]
[[package]]
name = "pbkdf2"
version = "0.12.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f8ed6a7761f76e3b9f92dfb0a60a6a6477c61024b775147ff0973a02653abaf2"
dependencies = [
"digest",
]
[[package]]
name = "pem"
version = "3.0.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8e459365e590736a54c3fa561947c84837534b8e9af6fc5bf781307e82658fae"
dependencies = [
"base64",
"serde",
]
[[package]]
name = "pem-rfc7468"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "88b39c9bfcfc231068454382784bb460aae594343fb030d46e9f50a645418412"
dependencies = [
"base64ct",
]
[[package]]
name = "pin-project-lite"
version = "0.2.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bda66fc9667c18cb2758a2ac84d1167245054bcf85d5d1aaa6923f45801bdd02"
[[package]]
name = "pkcs8"
version = "0.10.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f950b2377845cebe5cf8b5165cb3cc1a5e0fa5cfa3e1f7f55707d8fd82e0a7b7"
dependencies = [
"der",
"spki",
]
[[package]]
name = "ppv-lite86"
version = "0.2.20"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "77957b295656769bb8ad2b6a6b09d897d94f05c41b069aede1fcdaa675eaea04"
dependencies = [
"zerocopy",
]
[[package]]
name = "primeorder"
version = "0.13.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "353e1ca18966c16d9deb1c69278edbc5f194139612772bd9537af60ac231e1e6"
dependencies = [
"elliptic-curve",
]
[[package]]
name = "proc-macro2"
version = "1.0.86"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5e719e8df665df0d1c8fbfd238015744736151d4445ec0836b8e628aae103b77"
dependencies = [
"unicode-ident",
]
[[package]]
name = "quote"
version = "1.0.37"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b5b9d34b8991d19d98081b46eacdd8eb58c6f2b201139f7c5f643cc155a633af"
dependencies = [
"proc-macro2",
]
[[package]]
name = "rand"
version = "0.8.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "34af8d1a0e25924bc5b7c43c079c942339d8f0a8b57c39049bef581b46327404"
dependencies = [
"libc",
"rand_chacha",
"rand_core",
]
[[package]]
name = "rand_chacha"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e6c10a63a0fa32252be49d21e7709d4d4baf8d231c2dbce1eaa8141b9b127d88"
dependencies = [
"ppv-lite86",
"rand_core",
]
[[package]]
name = "rand_core"
version = "0.6.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ec0be4795e2f6a28069bec0b5ff3e2ac9bafc99e6a9a7dc3547996c5c816922c"
dependencies = [
"getrandom",
]
[[package]]
name = "rfc6979"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f8dd2a808d456c4a54e300a23e9f5a67e122c3024119acbfd73e3bf664491cb2"
dependencies = [
"hmac",
"subtle",
]
[[package]]
name = "rustc_version"
version = "0.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cfcb3a22ef46e85b45de6ee7e79d063319ebb6594faafcf1c225ea92ab6e9b92"
dependencies = [
"semver",
]
[[package]]
name = "sec1"
version = "0.7.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d3e97a565f76233a6003f9f5c54be1d9c5bdfa3eccfb189469f11ec4901c47dc"
dependencies = [
"base16ct",
"der",
"generic-array",
"pkcs8",
"subtle",
"zeroize",
]
[[package]]
name = "semver"
version = "1.0.23"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "61697e0a1c7e512e84a621326239844a24d8207b4669b41bc18b32ea5cbf988b"
[[package]]
name = "serde"
version = "1.0.210"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c8e3592472072e6e22e0a54d5904d9febf8508f65fb8552499a1abc7d1078c3a"
dependencies = [
"serde_derive",
]
[[package]]
name = "serde_derive"
version = "1.0.210"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "243902eda00fad750862fc144cea25caca5e20d615af0a81bee94ca738f1df1f"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "sha2"
version = "0.10.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "793db75ad2bcafc3ffa7c68b215fee268f537982cd901d132f89c6343f3a3dc8"
dependencies = [
"cfg-if",
"cpufeatures",
"digest",
]
[[package]]
name = "signature"
version = "2.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "77549399552de45a898a580c1b41d445bf730df867cc44e6c0233bbc4b8329de"
dependencies = [
"digest",
"rand_core",
]
[[package]]
name = "spki"
version = "0.7.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d91ed6c858b01f942cd56b37a94b3e0a1798290327d1236e4d9cf4eaca44d29d"
dependencies = [
"base64ct",
"der",
]
[[package]]
name = "subtle"
version = "2.6.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "13c2bddecc57b384dee18652358fb23172facb8a2c51ccc10d74c157bdea3292"
[[package]]
name = "syn"
version = "2.0.77"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9f35bcdf61fd8e7be6caf75f429fdca8beb3ed76584befb503b1569faee373ed"
dependencies = [
"proc-macro2",
"quote",
"unicode-ident",
]
[[package]]
name = "thiserror"
version = "1.0.63"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c0342370b38b6a11b6cc11d6a805569958d54cfa061a29969c3b5ce2ea405724"
dependencies = [
"thiserror-impl",
]
[[package]]
name = "thiserror-impl"
version = "1.0.63"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a4558b58466b9ad7ca0f102865eccc95938dca1a74a856f2b57b6629050da261"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "tracing"
version = "0.1.40"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3523ab5a71916ccf420eebdf5521fcef02141234bbc0b8a49f2fdc4544364ef"
dependencies = [
"pin-project-lite",
"tracing-attributes",
"tracing-core",
]
[[package]]
name = "tracing-attributes"
version = "0.1.27"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "34704c8d6ebcbc939824180af020566b01a7c01f80641264eba0999f6c2b6be7"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "tracing-core"
version = "0.1.32"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c06d3da6113f116aaee68e4d601191614c9053067f9ab7f6edbcb161237daa54"
dependencies = [
"once_cell",
]
[[package]]
name = "typenum"
version = "1.17.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "42ff0bf0c66b8238c6f3b578df37d0b7848e55df8577b3f74f92a69acceeb825"
[[package]]
name = "unicode-ident"
version = "1.0.13"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e91b56cd4cadaeb79bbf1a5645f6b4f8dc5bde8834ad5894a8db35fda9efa1fe"
[[package]]
name = "version_check"
version = "0.9.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0b928f33d975fc6ad9f86c8f283853ad26bdd5b10b7f1542aa2fa15e2289105a"
[[package]]
name = "wasi"
version = "0.11.0+wasi-snapshot-preview1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9c8d87e72b64a3b4db28d11ce29237c246188f4f51057d65a7eab63b7987e423"
[[package]]
name = "wasm-bindgen"
version = "0.2.93"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a82edfc16a6c469f5f44dc7b571814045d60404b55a0ee849f9bcfa2e63dd9b5"
dependencies = [
"cfg-if",
"once_cell",
"wasm-bindgen-macro",
]
[[package]]
name = "wasm-bindgen-backend"
version = "0.2.93"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9de396da306523044d3302746f1208fa71d7532227f15e347e2d93e4145dd77b"
dependencies = [
"bumpalo",
"log",
"once_cell",
"proc-macro2",
"quote",
"syn",
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-macro"
version = "0.2.93"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "585c4c91a46b072c92e908d99cb1dcdf95c5218eeb6f3bf1efa991ee7a68cccf"
dependencies = [
"quote",
"wasm-bindgen-macro-support",
]
[[package]]
name = "wasm-bindgen-macro-support"
version = "0.2.93"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "afc340c74d9005395cf9dd098506f7f44e38f2b4a21c6aaacf9a105ea5e1e836"
dependencies = [
"proc-macro2",
"quote",
"syn",
"wasm-bindgen-backend",
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-shared"
version = "0.2.93"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c62a0a307cb4a311d3a07867860911ca130c3494e8c2719593806c08bc5d0484"
[[package]]
name = "zerocopy"
version = "0.7.35"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1b9b4fd18abc82b8136838da5d50bae7bdea537c574d8dc1a34ed098d6c166f0"
dependencies = [
"byteorder",
"zerocopy-derive",
]
[[package]]
name = "zerocopy-derive"
version = "0.7.35"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "fa4f8080344d4671fb4e831a13ad1e68092748387dfc4f55e356242fae12ce3e"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "zeroize"
version = "1.8.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ced3678a2879b30306d323f4542626697a464a97c0a07c9aebf7ebca65cd4dde"

16
blog/helpers/fake-openssh-key/Cargo.toml Normal file
View file

@ -0,0 +1,16 @@
[package]
name = "fake-openssh-key"
version = "0.1.0"
edition = "2021"
[lib]
crate-type = ["cdylib"]
[profile.release]
lto = true
opt-level = "s"
[dependencies]
cluelessh-keys = { git = "https://github.com/Noratrieb/cluelessh.git", version = "0.1.0" }
getrandom = { version = "0.2.15", features = ["js"] }
wasm-bindgen = "0.2.93"

7
blog/helpers/fake-openssh-key/README.md Normal file
View file

@ -0,0 +1,7 @@
# helper binary
`wasm-pack build --target web`
built with
- wasm-pack 0.12.1
- rustc 1.83.0-nightly (26b5599e4 2024-09-06)

51
blog/helpers/fake-openssh-key/src/lib.rs Normal file
View file

@ -0,0 +1,51 @@
use cluelessh_keys::{
private::{KeyEncryptionParams, PlaintextPrivateKey, PrivateKey},
public::{PublicKey, PublicKeyWithComment},
};
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn generate_fake(public_key: &str) -> Result<String, String> {
let public_key = public_key
.parse::<PublicKeyWithComment>()
.map_err(|err| format!("invalid public key: {err}"))?;
let mut fake_private_key = PlaintextPrivateKey::generate(
"".into(),
cluelessh_keys::KeyGenerationParams {
key_type: match public_key.key {
PublicKey::Ed25519 { .. } => cluelessh_keys::KeyType::Ed25519,
PublicKey::EcdsaSha2NistP256 { .. } => cluelessh_keys::KeyType::Ecdsa,
},
},
);
match public_key.key {
PublicKey::Ed25519 { public_key } => {
let PrivateKey::Ed25519 {
public_key: fake_public_key,
..
} = &mut fake_private_key.private_key
else {
panic!()
};
*fake_public_key = public_key;
}
PublicKey::EcdsaSha2NistP256 { public_key } => {
let PrivateKey::EcdsaSha2NistP256 {
public_key: fake_public_key,
..
} = &mut fake_private_key.private_key
else {
panic!()
};
*fake_public_key = public_key;
}
}
let fake_private_key = fake_private_key
.encrypt(KeyEncryptionParams::plaintext())
.map_err(|err| format!("failed to encode key: {err}"))?;
Ok(fake_private_key.to_bytes_armored())
}

1
blog/themes/terminal Submodule

@ -0,0 +1 @@
Subproject commit b6c2bafbdc30a43ff69b4e00d1aefcc49d7e4aaa