HN user
https://github.com/vngzs https://keybase.io/vngzs
[ my public key: https://keybase.io/vngzs; my proof: https://keybase.io/vngzs/sigs/JW88RqiRCJqnuZ_59waFsjWNKkHQ8c9ejTJR4JXX_mE ]
Comments are my opinion and not intended to represent the viewpoint of my employer (past or present).
It lets organizations (Tailscale) control the timing and narrative around the disclosure more directly. Organizations sometimes avoid the bureaucracy of going through CVE Numbering Authorities by self-publishing. Often a CVE assignment follows self-disclosure, especially when there's pressure to interoperate with vuln-scanning/compliance tooling
How do you manage to coax public production models into developing exploits or otherwise attacking systems? My experience has been extremely mixed, and I can't imagine it boding well for a pentesting tools startup to have end-users face responses like "I'm sorry, but I can't assist you in developing exploits."
I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
For support matrices, see [1].
Curious what the threat model for the cryptographic verification is. It looks like verify_signature_software[1] doesn't actually verify ed25519 signatures, but rather computes a truncated sha512 hash of the data and compares that with the supplied hash.
fn verify_signature_software(&self, data: &[u8], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
let mut h = [0u8; 64];
let data_hash = self.compute_sha512(data);
for i in 0..32 {
h[i] = data_hash[i];
}
self.verify_ed25519_reduced(h, signature)
}
fn verify_ed25519_reduced(&self, h: [u8; 64], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
// ...
let mut matches = true;
for i in 0..32 {
if signature[i] != h[i] {
matches = false;
break;
}
}
// ...
matches && key_valid
}
It is difficult to comment on the verification approach when there are no secrets and only hash verification occurs. Do you have documentation on the approach and future plans? At best, this "signature verification" looks like placeholders for future verification.
[0] https://github.com/JGiraldo29/vekos/blob/d34e6454f3f7290e4b5...
[1] https://github.com/JGiraldo29/vekos/blob/d34e6454f3f7290e4b5...
Does this mean rewriting Magit to use libgit2 FFI bindings[0] rather than subprocess calls would lead to significant speedups?
It's a Linux phone that runs Android apps, so they ostensibly don't have the problem of building the ecosystem.
It's "fury phone":
Furious Support from the FuriOS team
There's a binary analysis time travel debugger similar to this, Qira [0][1].
[0] https://www.usenix.org/conference/enigma2016/conference-prog...
[1] https://qira.me/
We're not, and they're still in the process of discussion. It seems a bit early to fork and witch-hunt [0]:
So clarification here: you asked me about that, but I haven’t been able to respond to you due to my illnesses and I’m just getting back on my feet now. So it’s not that it hasn’t been well received, it’s that I’ve been physically unable to respond to you.
[0] https://github.com/go-gitea/gitea/pull/24257#issuecomment-23...
It's not a complete mitigation, but you can pause your video history which may decrease the amount of information Google retains over time from this sort of analytics. I haven't dug into the privacy policy and I'm not sure it mentions if this feature affects backend data collection, however.
There's actually a Slate article covering this topic[0]. First, consent was given for certain homes. However, the article also notes that under "exigent circumstances" warrantless searches are permitted:
In exigent circumstances, or emergency situations, police can conduct warrantless searches to protect public safety. This exception to the Fourth Amendment’s probable cause requirement normally addresses situations of “hot pursuit,” in which an escaping suspect is tracked to a private home. But it might also apply to the events unfolding in Boston if further harm or injury might be supposed to occur in the time it takes to secure a warrant. A bomber believed to be armed and planning more violence would almost certainly meet such prerequisites.
[0] https://slate.com/news-and-politics/2013/04/boston-bomber-ma...
I think you'll find "distributed decision-making" is no panacea. I joined a company recovering from a distributed governance model, and the big challenge was that nobody had enough decision-making authority for the firm to change quickly and respond to the evolving outside world. Bringing a whole room to consensus is a lot tougher than getting a few people to disagree-but-commit and move on with their day.
Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.
This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.
Links are just for reference, but the gist is: serve the webapp from the Go binary instead. The end-user already has to trust the Go binary, and if they need to they can look at the code once and confirm it's not vulnerable. I prefer this to browser extensions because the audit trail process from source to browser extension is less clear; even for open-source browser extensions, I still have to trust the author to not add code that isn't in the repository.
You're very right! Luckily, we can resolve the vulnerability in this instance, although it's a challenging problem to resolve in general webapps.
The technical explanation for our issue is that the client-side Javascript in our webapp is trusted. To quote the late Ross Anderson [0, pg. 13], "a trusted system or component is one whose failure can break the security policy." In this case, our security policy is that the server must not be capable of viewing our screenshots. Our goal is to make that trusted Javascript more trustworthy: that is, closer to a system that can't fail.
We're at an advantage in this case: there's an open-source application on GitHub with eyeballs[1] on it that users must run on their endpoint machines. Given that we already have source-available local code running, we could instead serve the UI from the local Go application and use CORS[2] to permit access to the remote server. If the local application is trustworthy, and we're only sending data (not fetching remote Javascript), then the local client UI is trustworthy and won't steal your keys. If users run binaries directly from 1fps (as opposed to building from source), then you would want some multi-party verification that those binaries correspond directly to the associated source [3].
Protonmail is almost surprising: it's supposed to be end-to-end encrypted, but it's not end-to-end encrypted in the presence of a malicious server. If, say, a government order compelled Protonmail to deploy a backdoor only when a particular client visited the site, most users would be unaffected and the likelihood of discovery would be low.
[0] https://www.cl.cam.ac.uk/~rja14/book.html
[1] https://en.wikipedia.org/wiki/Linus%27s_law
AES-GCM has more issues than merely the nonce reuse in the context of random nonces. For instance, the short tag issue[0] leaks authentication (not encryption) keys after a probabilistic "forged" message.
In general, the move in modern cryptography engineering is to assume the end user does not know what they are doing. For GCM, you have to get the nonces right and you need the right tag length, and the design uses lookup tables so it's prone to timing attacks in many implementations.
Later on I didn't just recommend an algorithm but a specific implementation (at least if we can find a better method of symmetric key distribution): nacl/secretbox [1]. This is a cryptographic library designed to be misuse-resistant, a property of cryptographic designs that makes implementation errors more difficult. nacl is a few years behind the curve inasmuch as it arguably gives the end-user too much control over key generation, but it permits random nonces (being based upon XSalsa) and provides a simple API that is difficult to mess up.
AES-GCM is secure with a correct implementation, but to build a correct implementation you often need to know the specific library inputs and configuration settings to produce your desired outcome. Something like secretbox doesn't give you those options: you get one relatively secure configuration ... and that's it!
[0] https://csrc.nist.gov/csrc/media/projects/block-cipher-techn...
I assume there's TLS in the server connection already, but the encryption here is to make the communication unavailable to the server for decryption, so "bare" TLS does not solve the problem.
With TLS you need pubkeys you can trust (the certificate authority hierarchy provides that trust for the open Internet) or you're vulnerable to MITM. You could potentially share pubkeys using a similar out-of-band mechanism to that currently used for symmetric key distriubtion, and tunnel that TLS connection through the server's shared comms channel. That would work OK for two parties, but it becomes significantly more cumbersome if you want three or more, since each TLS session is a pairwise key exchange. Notably, however, this would not transit secret keys through server-controlled web pages where they could be available to Javascript. Something like Noise [0] might also be useful for a similar pubkey model.
Unfortunately, this kind of cryptography engineering is hard. Key distribution and exchange is hard. There isn't much of a way around learning the underlying material well enough to find this sort of issue yourself, but misuse-resistant libraries can help. Google's Tink [1] is misuse-resistant and provides a handful of blessed ways to do things such as key generation, but I'm not sure if it's suitable outside of cloud deployments with KMS solutions. nacl/secretbox handles straight encryption/decryption with sound primitives, but it still requires a correct means of key generation [2] and distribution.
[0] http://www.noiseprotocol.org/noise.html
You will still need to get the nonce and key generation right, but I'd recommend using Golang's nacl/secretbox [0] for a project such as this. It's designed to be relatively misuse-resistant compared to using underlying primitives directly, and under the hood it's XSalsa20+Poly1305 - so you can use random nonces with negligible collision risk.
Good job releasing your project! It's a cool idea and surprisingly minimalist. That said, I've found a number of cryptographic flaws in the application source. This should not be used in instances where the encryption is mission-critical.
1) You generate a random key [0] and then feed it into PBKDF2 [1] to generate a 32-byte AES-GCM key. If you can generate 32 random bytes instead of 10 reduced-ASCII characters and a key stretch, just do that. PBKDF2 is for turning a password into a key, and it's far from the recommended algorithm nowadays; prefer scrypt if you need to do this sort of thing.
2) AES-GCM with random 12-byte nonces. Never use random IVs with GCM; this breaks the authentication [2] [3]. Given the pitfalls of AES-GCM with respect to random nonces, you might prefer switching to XSalsa20+Poly1305. The advantage of XSalsa is it has an extended nonce length, so you can use random nonces without fear.
3) Random key derivation with a restricted character set can make brute force attacks easier. You should have a 256-bit random key, and if you want that key to be within a certain character set, then encode the byte output from the CSPRNG using that character set.
4) 1fps achieves symmetric key distribution via a URL with a fragment identifier ("#") which IIRC is not sent to the server. Therefore it assumes you have a secure key distribution channel - the link contains the key, so it's important that only the intended recipient can view the part after the "#". If the server is truly malicious, it can deploy client-side Javascript to send the fragment to the server, allowing the server to access the key (and thus cleartext communication).
[0] https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L99
[1] https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L287
Agreed. The Linux kernel source contains everything you need to produce Linux kernel binaries. The llama source does not contain what you need to produce llama models. Facebook is using sleight of hand to garner favor with open model weights.
Open model weights are still commendable, but it's a far cry from open-source (or even libre) software!
Either the court or his lawyers.
Experiments with human cells and mice have shown oxidative stress, neurotoxicity, reproductive toxicity, carcinogencity, and altered metabolism.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10151227/
If you ask me, plastic is the new lead.
In the vast majority of America, there is no serious high-speed internet competition.
Paxos | SecOps | USA+Canada | Full-time | Fully remote | https://www.paxos.com
Paxos is building a fully-regulated, foundational blockchain infrastructure platform to enable the instant movement of any asset, at any time, in a trustworthy manner. Our customers include some of the world’s leading financial institutions, like PayPal, Venmo, Mastercard, and Interactive Brokers.
We are fully-remote, and compensation is not location-adjusted.
We're currently looking for:
- Staff SecOps Security Engineer -> https://paxos.com/job-posts/staff-security-engineer/
I would describe this spyware's "illegal" status as colloquially true - despite the lack of a comprehensive, international, enforceable legal framework - at least in the USA [0]:
As part of this effort, the End-User Review Committee of the BIS decided to add four foreign entities, among them two Israeli companies, NSO Group and Candiru, to the Entity List. The U.S. Export Administration Regulations (‘EAR’) impose additional license requirements for exports to listed entities, and limits the exceptions for exports, reexports, and transfers to such entities.
But they continue:
The existing international and national frameworks regulating the export of sensitive spyware technologies lack the teeth necessary to deal with contemporary issues relating to the abuse of these technologies and the growing need for their enhanced supervision.
[0] https://www.law.georgetown.edu/ctbl/blog/managing-risky-busi...
Ephemeral key handshakes are blocked by enterprises that do TLS decryption.
Funny this doesn't mention structured equity. Matt Levine touched on this in a recent Money Stuff column for Bloomberg Opinion, and he had a way to turn this problem into a business model:
There are, these days, a lot of startups that used to be worth $1 billion and are now worth $500 million. Some of them raised money at $1 billion valuations, back in the good times, and now they need to raise money again. It is, for some combination of good and bad reasons, extremely undesirable for a startup that raised money at $1 billion to raise money again at $500 million. Therefore there is a business opportunity for a fund that will:
1. Give startups money at a $500 million valuation, but
2. Say that it’s at a $1 billion valuation.
This is called “structure,” or “structured equity.” Bloomberg’s Gillian Tan reported Friday:
> Philippe Laffont’s Coatue Management raised about $3 billion for a structured equity fund that allows closely held companies to avoid raising money at lower valuations, a person with knowledge of the matter said.
> With the market for initial public offerings in a funk and lower risk appetite from large venture capital investors, some startups have sought to raise convertible notes and pursue structured financings instead of accepting a lower valuation through a traditional equity funding round.
That claim isn't made on the linked site, though. I think people who write C nowadays tend to be working in the drivers and OS development spaces.
Indeed, in CCC's "systematic evaluation of OpenBSD's mitigations"[0] the presenter explicitly calls out OpenBSD's tendency to present mitigations without specific examples of CVEs it defeats or exploit techniques the mitigations are known to defend against:
Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills this CVE; it delays production of an exploit by one week." And also thorough testing by seasoned exploit writers. Anything else is relying on pure luck, superstition, and wishful thinking.
Some of OpenBSD's mitigations are excellent and robust in defensiveness; others are amorphous and not particularly useful.
You can get them on ebay: