Users are asked to generate, memorize, and keep secret a growing number of passwords as they join new password-protected sites over time. Since at least 1997 [6], this trend has been recognized as both a nuisance and a security risk.
Post
Replies:
14
Boosts:
2
CoMPS is not only immediately deployable with any unaltered server that supports connection migration,
lol
Many other defenses also involve obfuscating packet timing,
this will be good
either by injecting “dummy” packets
nope
or intentionally delaying packet delivery [14, 24].
can't believe he didn't even cite chaum on mixnets
https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf
bruh
It has been proposed that to improve performance, the node-to-node communication
should be by unreliable datagrams (UDP), rather than the current reliable in-order streams
(TCP).
tor took until 2011 to stop using fucking vint cerf's replay attack protocol???? cmon
https://www.freehaven.net/anonbib/papers/pets2013/paper_65.pdf
Although Tor’s primary goal is to support real-time interactive applications such as web browsing
oh, so tor's primary goal is to make sure packet latency can be tracked
∗An extended version of this paper is available [1]
literally goes to a site with a broken HTTPS certificate https://www.cacr.math.uwaterloo.ca/techreports/2013/cacr2013-16.pdf
now i'm checking out uwaterloo https://uwaterloo.ca/cybersecurity-privacy-institute/research
Modern cryptography concerns itself with the following four objectives:
- Confidentiality: The information cannot be understood by anyone for whom it was unintended
- Integrity: The information cannot be altered in storage or transit between sender and intended receiver without the alteration being detected
- Non-repudiation: The creator/sender of the information cannot deny at a later stage their intentions in the creation or transmission of the information
- Authentication: The sender and receiver can confirm each other's identity and the origin/destination of the information
literally all the fascist use cases and not anonymity. you have "privacy" in your institute's name my dawg
lmao omg
Pseudorandom Bit Generation
they specifically have "subtly broken sources of randomness" as a research field
https://uwaterloo.ca/scholar/ggong
the name attached simply goes to their home page
https://uwspace.uwaterloo.ca/items/89bf1e6d-6fe4-44b7-9aa6-fd311a75cef4
Towards more Effective Censorship Resistance Systems
this guy is funny
We design and deploy a privacy-preserving data gathering tool, and use it to collect statistics
https://crysp.uwaterloo.ca/prospective/
they say they're looking for grad applicants
they would kill me
- "reliable systems" group
- click first paper: https://rcs.uwaterloo.ca/pubs/sosp21-aurora.pdf
- it's literally a meme
Applications on modern operating systems manage their ephemeral state in memory and persistent state on disk. Ensuring consistency between them is a source of significant developer effort and application bugs.
yeah cause there's no API for it
We present the Aurora single level store, an OS that eliminates the distinction between ephemeral and persistent application state.
literally the lobotomy OS
Another problem with existing and prior single level stores is their incompatibility with the ubiquitous POSIX API.
this is just false. this is why i emailed POSIX
Aurora has three main challenges: First, POSIX state is inherently difficult to capture as state spans both userspace and the kernel, and is not always associated with a process.
false. POSIX state is the page cache, which makes every file write visible everywhere at once, enabling security vulnerabilities through mktemp
Second, saving application state frequently requires incremental tracking to reduce system overhead.
mine solves this
Third, the bulk of the state is memory that is tracked using the memory management unit (MMU), adding runtime overhead.
literally the opposite of correct
@hipsterelectron False. POSIX state is not "the page cache", a concept not even dfined in POSIX.
The state actually is large and difficult to capture and spans userspace (generally manifesting as libc globals) and kernelspace (state that is necessarily privileged to modify because it affects relationships to other processes or to resource ownership and system-wide state).
What I would call "the largely kernelspace portion of POSIX state" is defined in https://pubs.opengroup.org/onlinepubs/9799919799/functions/execve.html and https://pubs.opengroup.org/onlinepubs/9799919799/functions/fork.html
@dalias write() being immediately globally visible is a completely fucked semantic
@hipsterelectron I disagree but that's not even the "POSIX state" of the process. It's the state of an external object the process acts upon.
@dalias yes i completely agree with you there. my mental model of how memory should work is not the one POSIX requires for conformance
@dalias i believe very strongly in:
(a) limiting the synchronization over file paths to named "sync contexts" (defaulting to global)
(b) maintaining scratch space in the current process's virtual memory mapping to record all modifications to file regions until explicitly committed to a named sync context
(c) explicitly committing all the filesystem state modifications from a sync context to disk (with something like fsync(), just instead of per-fd it's for an entire set of modifications)
