> You mean like AESENC which you should always be using if available?
Yes. And make it not unsafe
> Sometimes it's the only way to get some sort of constant time guarantees
I don't think you understood the article then. Brian wants the constant time guarantees as an intrinsic in the std library, guaranteed by the compiler, and exposed as safe rust.
> The rust fanclub obsession with calling things like that unsafe simply because it has the same keyword in front of it is fairly ridiculous.
If you have to use the unsafe keyword, you're creating the possibility of memory safety vulnerability. It would be amazing if you could immediately see that all code in a library does not use unsafe and know an entire class of vulnerabilities does not exist
I was sure it's something else, never heard of this being a standard term. Google search gives me only movie characters, "name meaning" pages, and a project called "Mallory in the middle" that implements some specific man-in-the-middle attack.
I guess it's another case of those "raising awareness" changes, that is supposed not to cost anything, but just made me spend like 4 min confusedly googling what the new term means.
I released a MiTM tool over a decade ago at BlackHat named Mallory. It is the common name for a malicious actor in between Alice and Bob in cryptography explanation.
You mean calling the adversary Mallory? Yes, this is standard. The term mallory-in-the-middle is not, as you can confirm with one Google search. There's barely anyone using this term, and nobody was using it 4 years ago.
At first, I thought that Mallory-in-the-middle was some special type of man-in-the-middle attack. In crypto, Mallory is a very specific type of adversary (active one, I think).
Mallory is used to refer to active network exploitation (as opposed to Eve, who is passive). "Mallory-in-the-middle" is a great term that actually makes the attacker capabilities more clear and should already be understood by people with relevant context. The default "let's remove gendered terms" approach would be "person-in-the-middle."
Most MITM attacks that we care about are active attacks (hence Mallory.) An eavesdropper-in-the-middle attack would just be the standard attack setting, not an MITM. For those who are experts the term is “MITM” and I don’t care what the first M stands for.
> There's barely anyone using this term, and nobody was using it 4 years ago.
At my employer (security consultancy in Germany), we switched ~two weeks ago from "man" in the middle to "machine" in the middle as expansion for the MITM acronym. Mallory is also a good option, although more known to cryptographers than our mainly developer audience (who might have more of an idea what a machine is than a Mallory). It's all not perfect but we're figuring this out. Yes, neutral gender writing is indeed relatively new and won't be much on web searches. Apparently some others use AiTM for attacker in the middle (yes, with that capitalization), which most people hated and voted against (because capitalizing the The but not the in looks dumb and, also, everyone already knows mitm so that change harms readability even more). It'll be a while before the community settles on something and "man" is not the most commonly known one. Bear with us until then!
Especially in Germany, albeit with an outsider's perspective, I would say it's very clear how relevant it is how you speak of persons. There is no commonly accepted 'singular they' and e.g. 'teacher' is always male (you'd have to say 'teacheress' or 'teacherin', not sure how to translate it, and so what people do is say both every time they refer to any teacher/in).
When always having to gender every word, not being inclusive has a measurable effect. There are enough studies that show the effects of listing genders alongside job listings that are typical/historical male or female jobs, also in other languages with less gendering. English is a lot better as a language, in my opinion, but still if you say "he" when referring to the aforementioned "doctor" when, really, it could be a doctor of either gender using the patient portal, you are still reinforcing a bias.
I don't think it's unnecessary to include the other half of the population in general writing, even if nobody has studied the effect of a "man in the middle" specifically. There's enough evidence elsewhere so that we might as well just switch things over at hardly any cost of change and no cost at all afterwards.
I'm not saying this way of gathering people's opinions is completely useless, but it has big flaws. Being against this sort of feminist initiatives can get you labeled all sorts of things in the best case, and cancelled in the worst case.
It's like making a poll in Russia about whether citizens support the invasion of Ukraine or not, when saying you don't like it is a criminal offense that can get you in jail. "I just went out and asked some people on the streets of Moscow whether they support bombing of Ukraine, nobody said no while a couple of them said yes, so they must really like that."
This change wasn't an organised discussion but casually came up while writing a report: the writer changed the acronyms template text (for this report) from MITM to AiTM, he let the team know and asked whether the upstream (company-wide) template should be changed also. That sparked alternative suggestions like Machine instead of Attacker and we ended up going with that. It wasn't intended to be formal and vote-like. I'm not sure setting up an anonymous vote (on some third party system to avoid being able to see server logs) is feasible every time something like this comes up.
How would you say we could do better? I'm definitely open for ideas if there are feasible methods. (And if it's not a "feasible" method for this one-off, then it might still be a good thing for more general / organised opinion gathering.)
There's plenty of margin in the industry - as an anecdote, I've paid around £40 for a pair in the UK through an online retailer (Glasses Direct), around ~₹1500-2000 in India through an online retailer (Lenskart) and ~₹800 by visiting a local store in a Tier 2 city in India
I reckon that's now how SSI solutions use a blockchain (or at least the ones I know of). AFAIK, a blockchain is only used to resolve a DID (an identifier mapping a random ID to a bunch of public keys you control, along with a URL to communicate with your device). Your personal information, as in your name, phone number, email stay in your device and are only exchanged with the party you want to authenticate against.
I'm curious to know if there's something I misunderstood in this space
In case anyone's curious, in absence of a shebang (#!), Linux [1] returns an ENOEXEC to the execve syscall, after which the invoking program (the shell) handles the failure. Usually shells default to running the file as a shell script with itself as argv0.
This can lead to an interesting situation where a program will work if launched by a shell (or by another program that uses `execlp`), but will fail if it is launched with a different variant of `exec`. For example:
$ touch empty
$ chmod a+x empty
$ ./empty # Works
$ valgrind -q ./empty # Works
$ timeout 10s ./empty # Works
$ /usr/bin/time ./empty # Works
$ perl -e 'exec("./empty") or die' # Works
$ python -c 'import subprocess; subprocess.check_call("./empty", shell=True)' # Works
$ python -c 'import subprocess; subprocess.check_call("./empty")' # Fails
...
OSError: [Errno 8] Exec format error
$ ruby -e 'exec "./empty"' # Fails
-e:1:in `exec': Exec format error - ./empty (Errno::ENOEXEC)
from -e:1
$ strace ./empty # Fails
execve("./empty", ["./empty"], 0x7fff6639f3a0 /* 84 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++
It can be quite fun to track down why a program executes successfully and then later fails to execute, with no changes made to the program in between.
I knew this about the programming languages which wrap execution in a shell, but I never knew that execlp/execvp/execvpe handled ENOEXEC internally and wrapped the command in a shell too. TIL!
A fun consequence of this is that running a python script that doesn't have the shebang will mysteriously hang with a crosshair cursor until you click the mouse. When the shell encounters the first "import foo" line it tries to run ImageMagick's "import" utility which tries to take a screenshot of the selected window.
> If the execl() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2017, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126.
> A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.
The idea behind the definition is that it defines set of files that will not trigger various bugs in traditional unix text tools implementations (ie. various variants of not checking the fgets() return value).
I'd expect the same as any other failure from execv(2). Something like,
zsh: Exec format error: empty-file
(last command returned 127.)
(127 is the exit status for other failures, so I've used it here. The second line is intended to be part of my PS1, the first zsh's normal reporting. The string used here is what I get from perror() for that code.)
Status 129 or something else outside the usual range, plus a message that the file was not a valid ELF and also has no shebang, therefore cannot be executed.
I always thought that 128+ are for (shell-spawned) processes and 0-127 are for shell. But, apparently POSIX requires this behavior for empty files - we need to amend the standard, first (or fail to comply, muahahaha).
the multiple execution seems to be much slower with the empty executable than with /bin/true using the multitime tool https://tratt.net/laurie/src/multitime/
$ multitime -n 10 ./empty
===> multitime results
1: ./empty
Mean Std.Dev. Min Median Max
real 0.006 0.000 0.005 0.006 0.006
user 0.001 0.001 0.000 0.002 0.002
sys 0.000 0.001 0.000 0.000 0.002
$ multitime -n 10 /bin/true
===> multitime results
1: /bin/true
Mean Std.Dev. Min Median Max
real 0.002 0.000 0.001 0.002 0.003
user 0.001 0.000 0.001 0.001 0.001
sys 0.000 0.000 0.000 0.000 0.000
> What is also interesting is that while strace seems to report much less overhead in "./empty" compared to /bin/true
That's because it reports an error and does not actually execute the file.
>strace: exec: Erreur de format pour exec()
`strace` uses one of the exec()-style functions that don't automatically invoke a shell here. And if it did, it would invoke an entire shell (/bin/sh, typically), which might have more overhead.
----
You need to be very careful when measuring this, because what happens is that a shell executes the shebangless empty file.
If you try launching it from e.g. a C program using execlp(), it will have to first start that shell.
If you try launching it from e.g. bash, it might directly run that in-process or at least after a fork() or similar, skipping some of the shell setup.
> You /still/ have no way to ensure that the checkbox corresponded with the name, and that you cast the vote you think you did
Well the voter can verify if the voting machine is acting honestly by querying the salt used for encryption (refer to "How do you know your ballot was properly constructed?"). From an adversarial voting machine's perspective the chances of the voter validating the ballot is 0.5 and given the sensitivity of the elections, I'd imagine even one incident of foul play spreading like wildfire to raise alarms
