141–150 of 164 posts
Earlier quoted context omitted.
about 8Gbits/sec
Wow. Is that a full 8Gbit/sec of data per host or a logical 8Gbit/sec of raw frames? Either way, you're an ideal candidate for closed beta access to the performance focused container networking tools my startup is developing. I can contact you via email if you're interested.
Earlier quoted context omitted.
that's great, thanks for answering! I have not yet looked at Calico - I have OVS-VXLAN between my worker nodes, which is a simple solution that works great. Is it possible to say "use whatever is already in place"?
It may be possible by writing a slightly modified YAML file for the Clocker blueprint itself. To avoid dragging this thread further off-topic, please drop me a line at the email address in my profile, and I can probably help you.
Earlier quoted context omitted.
> Crypto is hard, but it's no harder than a lot of other hard things. Crypto is a LOT harder than some other things. 3d graphics programmers don't have to worry about side channel attacks through timing disclosures through random numbers returned over an HTTP GET. Physics simulations don't have to worry about tens to hundreds of millions of dollars of losses because Intel changed the L2 cache slightly in some revisio…
You're right, though there are some things that are about as hard: compilers, language design, machine learning, databases with strong ACID guarantees, etc. The problem I have with the "crypto should be a forbidden zone" line of reasoning is that the real world evidence shows that the old battle tested systems manifest flaws at least as often as competently designed newer systems do. Crypto, it turns out, is so hard…
Compiler design isn't that hard. A perfect optimizing compiler is damn nearly impossible, but good enough is easy. LLVM makes good enough compilers pretty easy, see the number of new languages that get posted to HN every month!
Machine Learning is hard to do right for non-trivial cases, but the only risk is you waste your investor's money and your customer's time, you don't risk identity theft (unless you are using machine learning to write crypto code maybe? :) )
Databases, yeah, everyone screws those up.
The real key is how many people are trying to break your system though. Crypto is exposed, your DB layer can have protections put on it to sanitize your data and rate limit how fast stuff comes in. You can clean up the data that goes into your machine learning algorithm (or use one that is resilient to x% of malicious data).
None of those defenses depend upon defending attacks of context switch timing in the CPU leaking data from a CPU that was releases 2 years after your code shipped through QA!
(and yes new CPU designs can cause problems in any code! But Intel and AMD work hard to avoid the major cases!)
Earlier quoted context omitted.
"they do not use a password hashing function" this is a bit of a facepalm whenever i hear this.
> "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto : "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final…
Furthermore, it's not clear to me what the use of the diffie-hellman is actually for. Perhaps I'm misreading or the linked document is an oversimplification, but... It appears that the public DH key is transferred without any authentication.
If the public DH key is transferred without any authentication, it's trivially MITMable and serves no purpose whatsoever. It's true that mixing in the password later solves MITM at that point, but... yeah: All of the privacy and integrity you could produce with the system described is what comes from the password.
Earlier quoted context omitted.
> "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto : "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final…
What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF",…
What is the weakness with this approach? Is your point that there's nothing gained from doing the DH - you may as well just generate a secret key randomly, exchange that between the peers in the clear, and still have them combine that with the password secret, and the level of information exposed is the same?
I think there is a difference. Say you have a captured stream of traffic and you want to decrypt it. With the simpler non-DH scheme, you already have the basic key, so all you need to do is guess the password, and run that through sha256 and then you can decrypt the entire stream. Now you have the password, you can decrypt every stream you capture from now on. But with the DH scheme, you have to both guess the password, and the ephemeral private keys which are never exchanged (either that, or break Curve25519). Even once you've done that, you only get access to that one captured stream - sure, you now know the password, but every connection between weave routers will use different random private keys to their DH, so you'll still have to brute force those for every stream you capture (or, again, break Curve25519). So ISTM there is a substantial difference there. That, to me, is the point of using the DH. But maybe I'm missing something... I'm slightly wondering whether people here are considering the use of DH and Public Key crypto by weave in the context of the usual "generate keys once and save them". This is just not the case in weave - weave generates fresh public and private keys for EVERY connection between routers.
There is no requirement for weave that the password is human readable. It can be supplied through a file, so you can happily dd if=/dev/random of=/my/weave/passwd bs=1k count=1 to create a suitable weave password
Earlier quoted context omitted.
> "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto : "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final…
What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF",…
Earlier quoted context omitted.
> "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto : "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final…
What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF",…
Earlier quoted context omitted.
> "they do not use a password hashing function" From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto : "The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final…
What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF",…
That is correct. I guess calling this a 'password' is perhaps misleading in our docs, since it could be seen as implying human-readability and cryptographic weakness. As msackman says, the 'password' can in fact be as strong as you like.
Looks like flannel only supports IPv4, while weave would work on IPv4 or IPv6. That's a huge difference IMHO, since one will work on any scenario.
Earlier quoted context omitted.
I don't; if anything, I personally find them too charitable and reasonable. Just admit that you (if you're the one who wrote that response; it's not exactly clear who's who in this discussion...) were being a bit of a twit and move on. We all do it; I do it, the girl next door does it, my grandma even does it and she's the nicest person I know. There's no shame in being honest about it.
No, for example it is 100% uncharitable and unreasonble to assert that "please" is sarcastic. The truth is quite the opposite.
Typically (at least in American English vernacular), "please" is very frequently used in a sarcastic manner (e.g. "You think you can jump from the top of that building and not get hurt? Bitch, please." or "Oh please, like you know the difference between a grape and a grapefruit."). While this sarcastic usage is usually accompanied by some other word prefixing it ("Oh please" or "Bitch please" or "Nigga please" or somesuch), it's not uncommon to see a lone "please" used in this sense as well, and the tweet in question very closely resembled that usage.