djmdjm

7 ms·

1.
by djmdjm 1mo ago
This was in the context of a contribution to add (IIRC) ext4 filesystem support to OpenBSD. In this case, I was worried that the AI was just regurgitating code that was in its training corpus because how many ext4 implementations are there?
2.
by djmdjm 1mo ago
If we did this in SSH then I think we should do it properly and take inspiration from TLS ESNI https://datatracker.ietf.org/doc/draft-ietf-tls-esni/25/
3.
OpenSSH 10.5 Released(openssh.org)
3 points by djmdjm 1mo ago|0 comments
4.
by djmdjm 1y ago
My understanding is that a hybrid using x25519 as the classical KEM is fine on the basis that the security of the construction rests (for the purposes of approval) on ML-KEM and can't be made worse by the other part of the hybrid algor
5.
by djmdjm 1y ago
FIPS certification is given to an entire "cryptographic module" that includes hardware and software. "FIPS compliant OpenSSH" is therefore a misnomer, you have to certify OpenSSH running on a particular OS on particular
6.
by djmdjm 1y ago
Those are completely disjoint threats. A captured SSH session should never be able to decrypted by an adversary regardless of whether it uses passwords or keys, or how weak the password is.
7.
by djmdjm 1y ago
>In light of the recent hilarious paper around the current state of quantum cryptography I assumed that paper was intended as a joke. If it's supposed to be serious criticism of the concept of quantum computing then it's pretty
8.
by djmdjm 1y ago
> - development time to switch things over This is a one time cost, and generally the implementations we're switching to are better quality than the classical algorithms they replace. For instance, the implementation of ML-KEM we us
9.
by djmdjm 1y ago
They don't endorse hybrid constructions but they also don't ban them. From the same document: > However, product availability and interoperability requirements may lead to adopting hybrid solutions.
10.
by djmdjm 1y ago
Yeah, key agreement in the context of SSH is quite forgiving of timing side channels as SSH uses ephemeral keys. There's no prospect of repeatedly re-doing the key agreement to gather more statistics on the counterparty's timing.
11.
by djmdjm 2y ago
You can help by testing/reviewing https://github.com/djmdjm/openssh-wip/pull/29/commits/659cbc...
12.
by djmdjm 2y ago
No, it's a fix. It completely removes the signal race as well as introducing a mitigation for similar future bugs
13.
by djmdjm 2y ago
Ubuntu isn't affected _by this exploit_
14.
by djmdjm 2y ago
Theo de Raadt made an, I think, cogent observation about this bug and how to prevent similar ones: no signal handler should call any function that isn't a signal-safe syscall. The rationale is that, over time, it's too way easy fo
15.
by djmdjm 2y ago
I'm confident that someone will make a workable exploit against 64-bit systems.
16.
by djmdjm 2y ago
OpenSSH release notes: https://www.openssh.com/txt/release-9.8 Minimal patches for those can't/don't want to upgrade: https://marc.info/?l=oss-security&m=171982317624594&w=2
17.
by djmdjm 2y ago
Yes: https://github.com/openssh/openssh-portable/commit/03e3de416...
18.
by djmdjm 3y ago
> The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication AFAIK this downgrade is not possible for OpenSSH, as it refuses RSA/SHA1 signatures by default at both the client an
19.
by djmdjm 3y ago
It also depends on the previous one for the PING/PONG messages used to simulate keystrokes and terminal echo: https://github.com/openssh/openssh-portable/commit/dce6d80d2...
20.
by djmdjm 3y ago
correct - this is for the post-auth session and not the authentication phase
21.
by djmdjm 3y ago
This is completely irrelevant to password based SSH authentication. The timing obfuscation is for the session _after_ authentication.
22.
by djmdjm 3y ago
This is irrelevant for SSH password authentication. The obfuscation is for the session _after_ authentication.
23.
by djmdjm 3y ago
yeah, keeping the total bandwidth used to be less than a dialup modem connection was an explicit goal when choosing the 20ms default interval.
24.
by djmdjm 4y ago
You can sign yubikey-hosted FIDO keys in OpenSSH just fine. A FIDO token can also act as CA, though the certificates it issues will be limited to use by relatively recent SSH versions as FIDO support was only added in 2019.
25.
by djmdjm 4y ago
Repeating this here. We (OpenSSH) have not disregarded NIST, we just added a PQ algorithm before NIST finished their competition and we'll almost certainly add support for the finalist fairly soon.
26.
by djmdjm 4y ago
We (OpenSSH) haven't "disregarded" the winning variants, we added NTRU before the standardisation process was finished and we'll almost certainly add the NIST finalists fairly soon.
27.
by djmdjm 7y ago
We don't ask anyone to learn CVS. People send the maintainers (myself and other) their changes (git format-patch is fine) and we integrate them.
28.
by djmdjm 7y ago
scp isn't part of the ssh protocol. It's a command that runs over it.
29.
by djmdjm 7y ago
actually, sftp is a bit more scriptable than scp. You can pass sftp a "batchfile" of commands and control per-command whether their success should terminate the batch. scp wins on brevity of commandline syntax
30.
by djmdjm 7y ago
yeah, pretty much. If someone implemented scp's command-line with sftp underneath then we could start the (slow) deprecation process.

More ›