Hacker News new | past | comments | ask | show | jobs | submit login

You can totally do asynchronous negotiation, and PGP has plenty of examples of it going wrong.

Edit: here's a beautiful recent example of in-band negotiation going wrong in an encryption at rest scheme. https://github.com/google/security-research/security/advisor...




This is completely the wrong place for this, but you don't list an email address and I don't want a Twitter account

In Dispatch #4 you complain (speaking of FIDO for OpenSSH) that "As far as I can tell, that’s true when the key handle is indeed an encrypted private key, but there’s nothing in the spec requiring that". In the WebAuthn spec. which I've actually read unlike the various other specifications, there are two alternatives offered:

1. At least 16 bytes that include at least 100 bits of entropy, OR

2. The public key credential source, without its Credential ID or mutable items, encrypted so only its managing authenticator can decrypt it. This form allows the authenticator to be nearly stateless, by having the Relying Party store any necessary state.


(The Reply-To of the Dispatches goes to my inbox!)

Nice! Both 1 and 2 should provide the security properties. Now I do wonder how the WebAuthn spec reflects the ecosystem of tokens compatible with OpenSSH. Honestly, I don't even know if OpenSSH implements WebAuthn or there's a different umbrella spec?


There are two separate specifications, FIDO and WebAuthn.

[Edited to add links:

https://www.w3.org/TR/2019/REC-webauthn-1-20190304/ and the current editor's draft https://www.w3.org/TR/webauthn-2/

https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl...

to give context]

I can't imagine there's actually a meaningful market for products that implement the hardware protocols described in FIDO (which use byte conservative CBOR because it's imagined that you'd try to run them over some ratty wireless protocol with no bandwidth) but aren't intended to be used with WebAuthn (which is full of JSON mapped to that CBOR because it's imagined you're a full fat modern web site displayed on a modern graphical web browser like Chromium or Firefox) but they are separate.

But OpenSSH doesn't need WebAuthn it just needs FIDO.

You'd presumably hate both specifications, because they drag in (and rely upon) registries for a bunch of technically unnecessary stuff and not even for the practical engineering reason I've excused in my sister posts to this thread. It's pure politics, you need everybody on the bus and so if they insist upon stupid ideas A, B and C between them then your options are veto A, B and C and nobody goes on the bus so the exercise was futile or you allow A, B and C with your face buried in your hands and plan for the inevitable negative security consequences.

Microsoft really wanted to do RSA for example. So, even though you wouldn't do RSA and I'm sure none of the Google people working on this love it either, the WebAuthn specification makes RSA an option and Microsoft shipped code that does RSA with WebAuthn.

I believe agl wanted the standards to rip out U2F's counters. Some security people love counters (does somebody have a war story where counters actually saved the day? I want to hear that war story) but others wanted them and so they are still in FIDO2/ WebAuthn even though they're a potential privacy hazard.

There are other examples.


I suppose you can make any at rest encryption scheme negotiate (even PGP) if you create such a negotiation system that uses the scheme as a primitive. I was only referring to the way such things are normally used. You make an encrypted file. After that the only way to decrypt it is the way it was encrypted.


> You make an encrypted file. After that the only way to decrypt it is the way it was encrypted.

Check out the linked S3 SDK vulnerability, it's precisely about decrypting a file in a different way from how it was encrypted :)


Looks like an oracle attack against malleable encryption. It does something clever to enhance the effectiveness of that attack but nothing there could reasonably be considered negotiation.


> Title: In-band key negotiation issue in AWS S3 Crypto SDK for golang




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: