So the server always sends the same plaintext (the private key of the bitcoin wallet), encrypted presumably by the same cipher but each time with a different symmetric key of course (negotiated by the handshake). It seems (naively, I'm sure) like this is a weakness, like you could collect a bunch of the encrypted samples, and then use the fact that they are all from the same plaintext in order to figure out what the plaintext is. How many samples would it take before you could deduce the key?
The Bitcoin Piñata
91–100 of 112 posts
Re: The Bitcoin Piñata
#92So the server always sends the same plaintext (the private key of the bitcoin wallet), encrypted presumably by the same cipher but each time with a different symmetric key of course (negotiated by the handshake). It seems (naively, I'm sure) like this is a weakness, like you could collect a bunch of the encrypted samples, and then use the fact that they are all from the same plaintext in order to figure out what the…
In theory, a block cipher is broken if an attacker can even tell the difference between application of the cipher and of a random permutation, different for each possible key, more efficiently than brute force (i.e. trying every possible key). Since encrypting the same plaintext with a bunch of different random permutations would not help an attacker recover it, I believe an attack like you describe would not be possible without breaking AES.
Re: The Bitcoin Piñata
#93Earlier quoted context omitted.
If you're not already, it'd be a good idea to log all traffic to/from the box so that you'll at least have something if no one owns up.
Ah, but it's so ironic if ipredator.se does that.
As far as I know, ipredator is not a service to prevent logging, they're a service to prevent unauthorized surveillance.
Re: The Bitcoin Piñata
#94Re: The Bitcoin Piñata
#95I'm more interested in the OS they hosted their site on. Mirage, developed in OCaml for the cloud. The part that really interested me: "If a sudden spike in traffic occurs, the web-servers can be configured to create and deploy copies of themselves to service the demand. This auto-scaling happens so quickly that an incoming connection can trigger the creation of new server and the new server can then handle that requ…
I should also have mentioned that Mirage is a core component of the stack for distributed personal clouds. We need to have resilient, scalable infrastructure if we want to own a piece of the cloud for ourselves.
http://nymote.org/blog/2013/introducing-nymote/ and http://amirchaudhry.com/brewing-miso-to-serve-nymote/
Re: The Bitcoin Piñata
#96Earlier quoted context omitted.
Syn flood...
Does mirage's TCP/IP stack implement syn cookies [0] when under attack? [0] http://lwn.net/Articles/277146/
I'm not keen on putting in SYN cookies and other DOS mitigations until the core TCP stack is really solid. TCP is a protocol that is a remarkable survivor in the face of small bugs that cause packet loss (fast retransmit kicks in, for example), but the manifestation of these bugs ends up being slow throughput.
The current thrust of the effort in the TCP stack is to make sure that we cover all the corner cases, and build a functional testing framework to check regressions and protocol traces versus other implementations. It's also quite remarkable how thin on the ground test suites are for TCP...
Once all this is done, then I have an alpha-grade multipath TCP implementation to merge in, and defences like SYN cookies will be parameterised options that can be activated in a unikernel in response to traffic surges.
Re: The Bitcoin Piñata
#97Earlier quoted context omitted.
I was reading the X509 certificate verification code, rather than the TLS code: https://github.com/mirleft/ocaml-x509/blob/master/lib/certif...
Why do you think this creates malleability? PKCS1.5 stripping takes away the leading 0x00 0x01 0xff ... 0x00 -- if this prefix is not present, it fails. The rest goes through the RSA tranform, and is parsed as PKCS1 DigestInfo, an ASN.1 structure. All ASN parsing checks for presence of trailing bytes, on top and in CONSTRUCTED nodes. The presence of suffix-checking prevents malleability in my mind. Am I missing somet…
ASN parsing code, in general, does not check for presence of trailing bytes (see Bleichenbacher's original signature forgery attack, and CVEs passim). Should they? Yes. Do they? No, it is a frequent implementation error.
In NSS, they did check for trailing bytes, but allowed one part of the ASN1 structure to have an arbitrary value (to work around flaws in other implementations).
To be abundantly clear: I am not saying that any of the presented code has an exploitable flaw. I am saying that the way the code is written has frequently been found to be faulty in the past.
Re: The Bitcoin Piñata
#98I'm more interested in the OS they hosted their site on. Mirage, developed in OCaml for the cloud. The part that really interested me: "If a sudden spike in traffic occurs, the web-servers can be configured to create and deploy copies of themselves to service the demand. This auto-scaling happens so quickly that an incoming connection can trigger the creation of new server and the new server can then handle that requ…
I have a bit of a problem understanding why this would be a good thing to be honest.
Capacity demand is handled by resource concurrency thresholds so why would spinning up a new OS (no matter how lightweight) be better than having non-blocking IO threads on a single kernel?
Re: The Bitcoin Piñata
#99Earlier quoted context omitted.
Ah, but it's so ironic if ipredator.se does that.
As far as I know, ipredator is not a service to prevent logging, they're a service to prevent unauthorized surveillance.
...preventing surveillance by running a vpn service and claiming not to have any kind of traffic logs, so yeah ;)
Re: The Bitcoin Piñata
#100I'm more interested in the OS they hosted their site on. Mirage, developed in OCaml for the cloud. The part that really interested me: "If a sudden spike in traffic occurs, the web-servers can be configured to create and deploy copies of themselves to service the demand. This auto-scaling happens so quickly that an incoming connection can trigger the creation of new server and the new server can then handle that requ…
I have a bit of a problem understanding why this would be a good thing to be honest. Capacity demand is handled by resource concurrency thresholds so why would spinning up a new OS (no matter how lightweight) be better than having non-blocking IO threads on a single kernel?
There is no reason the spun up OS can't also have non-blocking IO threads.
Mirage's philosophy is mainly about reducing attack surface and unnecessary overhead. That it makes the OS so small that you can boot it up in milliseconds is just an added benefit.