Is anybody aware of published analysis of this interesting construction, which seems to require what I will loosely term swear words to work? I believe I've only heard it in British English:
A1 - Dave got a job at Roche.
B1 - Fuck off did he! (=No he didn't; I don't believe you)
A2 -...
@CodesInChaos Ohh. It's nothing fancy. I'm just encrypting file contents on the client side before uploading it to dropbox. AES-128-CBC with HMAC applied.
@CodesInChaos I'm trying to make the whole thing as seamless as possible, so the file isn't encrypted when stored on the client-side. It's encrypted right before uploading it.
It obviously doesn't protect against bad things on the client-side.
I just re-encrypt the file when it's modified locally before uploading it.
@CodesInChaos I'm actually handling the synchronization on my own. What the Dropbox API offers is a way to put/remove files on their servers as well as obtain a "delta" of changes to a Dropbox folder.
Which is based on metadata, not the actual file contents.
Any idea how to create a certificate that is accepted for a TLS server (openssl s_server) using ECDH/RSA key exchange (like ECDH-RSA-AES128-SHA)? The openssl mailing list mentions that I need to have a keyAgreement usage and an "appropriate" curve. What is this curve? I have tried prime192v1 to no avail.
This is ECDH, not ECDHE. s_server is a test server provided by OpenSSL, nginx has the same issue with these ciphers (openssl ciphers -V | grep ECDH-RSA)
I hope it is not a bug in openssl, but rather my own mistaken/oversight
@Lekensteyn For this cipher suite, you need the certificate to contain an elliptic-curve key, and be signed by a CA which uses RSA.
You will have a hard time finding a client (browser) which can use that, though.
At least IE and Firefox will not use anything else than P-256 or P-384; that's the two "NSA suite B" curves, i.e. the bare minimum that must be implemented to claim "ECC support" in a US Federal way.
And then, I am not sure they would accept to decode or use a certificate with an ECDH public key.
wonder why .net's CSP and CNG crypto functions have such a huge per-call overhead. For SHA512's ComputeHash it's around 10k cycles using CNG and 100k cycles using CSP
@ThomasPornin Have you kept your answer? I have a feeling the question could be reworked into something useful - it is just extraordinarily broad as it currently stands.
@CodesInChaos When some manage code calls native code, the .NET VM inspects the whole stack of the calling thread, before and after the call, to make sure that it was not altered.
So the overhead is huge.
@RoryAlsop Actually my answer covers it already, I believe.
@CodesInChaos There is an attribute which can be declared, and which tells to the VM that such a check is not needed. I hypothesize that the Microsoft people forgot to specify it for their own usage.
@ThomasPornin Didn't we come to conclusion once it'd be best if you add a comment "bear territory" to the questions, so we all know we needn't bother posting puny answers? It should stop mods from closing the question too, I mean, if you have an answer to it, then it clearly shouldn't be closed and is a great question! :)
@ThomasPornin Thank you for the pointer, now that I use an RSA root CA for signing the EC certificate, ECDH-RSA works. What is the role of the root CA in this EC certificate? Are the public keys of this RSA CA somehow used for ECDH-RSA?
@Lekensteyn The CA key serves only to validate the server's certificate (i.e. to verify the signature on the certificate).
The indication of the CA key type in the cipher suite is a remnant from older times
It was supposed that a reduced TLS client would support only one type of signature algorithm and would specify that to the server, in case the server owns several certificates, signed by the same CA but with different keys of different types.
At that time, RSA was still patented, so the US federal government was pushing DSA + DH.
Therefore some people assumed that "normal" CA may have a RSA key and a DSA key, and would grant two certificates to a server.
In practice (now, and already at that time), everybody uses RSA, nobody uses DSA.
(at least for signing certificates)
@CodesInChaos Right now, I find that the most annoying part about C# and crypto is that Mono's BigInteger implementation is buggy.
So, the "RSA" in "ECDH-RSA" refers to the "Signature Algorirthm" field of a X509 certificate? And since a self-signed EC certificate does not have a RSA cipher, for this reason it cannot be used for ECDH-RSA right?
@Lekensteyn Yes, that's the theory. For the practice... it depends. Maybe the client and the server can use any kind of signature on the certificate and say "ECDH-RSA" like they would say "ECDH-Whatever". Or maybe not.
Is anybody aware of published analysis of this interesting construction, which seems to require what I will loosely term swear words to work? I believe I've only heard it in British English:
A1 - Dave got a job at Roche.
B1 - Fuck off did he! (=No he didn't; I don't believe you)
A2 -...
