Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bitcoin Piñata

ownme.ipredator.se

Post reply on HN
Print view View original

101–110 of 112 posts

Re: The Bitcoin Piñata

#101

Post by hannesm »

ctz wrote: post #97
pqwy wrote: post #53

Earlier quoted context omitted.

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 sayi…

"ASN parsing code, in general"... this sounds like you're a bit stuck in ad-hoc ASN.1 parsers written in C...

We actually use combinators for doing that - this explains our ASN.1 library in more depth: http://openmirage.org/blog/introducing-asn1

Re: The Bitcoin Piñata

#102

Post by ukigumo »

mtrimpe wrote: post #100
ukigumo wrote: post #98

Earlier quoted context omitted.

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.

Ok, but that would only be true if I was going to spin up a new vm to join the load group / cluster but even then no one would do that unless behind a reverse proxy / waf load balancer so the attack vector angle is covered.

I'm not saying MirageOS doesn't sound neat, I'm just not yet convinced it has a general purpose use case.

Re: The Bitcoin Piñata

#103

Post by copsarebastards »

ukigumo wrote: post #102
mtrimpe wrote: post #100

Earlier quoted context omitted.

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.

Ok, but that would only be true if I was going to spin up a new vm to join the load group / cluster but even then no one would do that unless behind a reverse proxy / waf load balancer so the attack vector angle is covered. I'm not saying MirageOS doesn't sound neat, I'm just not yet convinced it has a general purpose use case.

"General purpose use case" is an oxymoron.

Re: The Bitcoin Piñata

#104

Post by ukigumo »

copsarebastards wrote: post #103
ukigumo wrote: post #102

Earlier quoted context omitted.

Ok, but that would only be true if I was going to spin up a new vm to join the load group / cluster but even then no one would do that unless behind a reverse proxy / waf load balancer so the attack vector angle is covered. I'm not saying MirageOS doesn't sound neat, I'm just not yet convinced it has a general purpose use case.

"General purpose use case" is an oxymoron.

Are you sure? I'm usually very careful with my usage of figures of speech but I'm no language major so maybe I should clarify that I meant that I could see edge cases but not a general purpose one.

Did this clarify my point or in any other way contribute to your undestanding?

Re: The Bitcoin Piñata

#105

Post by amirmc »

ukigumo wrote: post #104
copsarebastards wrote: post #103

Earlier quoted context omitted.

"General purpose use case" is an oxymoron.

Are you sure? I'm usually very careful with my usage of figures of speech but I'm no language major so maybe I should clarify that I meant that I could see edge cases but not a general purpose one. Did this clarify my point or in any other way contribute to your undestanding?

MirageOS is useful for creating single-purpose appliances. That fits well with how the cloud is used today (where you typically end up with one service/app per VM anyway). The autoscaling piece is only one aspect and is only in the early stages, so you shouldn't dwell on it.

The overview page and the ASPLOS paper (linked upthread) and the ACM article [1] will help explain the benefits and trade-offs of the unikernel approach. Other people have also started using unikernels so you can read about their experiences too [2].

[1] http://queue.acm.org/detail.cfm?id=2566628

[2] http://amirchaudhry.com/unikernels-for-everyone/

Re: The Bitcoin Piñata

#106

Post by edwintorok »

zem wrote: post #87
edwintorok wrote: post #75

Earlier quoted context omitted.

Does mirage's TCP/IP stack implement syn cookies [0] when under attack? [0] http://lwn.net/Articles/277146/

i wasn't familiar with syncookies, but the article you linked to says > Syncookies are discouraged these days. They disable too many valuable TCP features (window scaling, SACK) and even without them the kernel is usually strong enough to defend against syn floods and systems have much more memory than they used to be. So I don't think it makes much sense to add more code to it, sorry.

You probably only want to enable syn cookies when you are under heavy attack, but from the same article:

"I can trivially prevent any inbound client connections with 2 threads of syn flood. Enabling tcp_syncookies brings the connection handling back up to 725 fetches per second."

"This data compellingly supports the continued value of the syncookie and that position seems to have won the day."

Of course this refers to the Linux TCP/IP stack, the Mirage stack is completely different so it remains to be seen what measures will be effective against syn floods.

Re: The Bitcoin Piñata

#107

Post by un1xl0ser »

MrRogers wrote: post #33

Where could I, a total beginner in crypto-stuff, learn more about this kind of thing? What would be the list of things I'd need to know how to do in order to "break in", and where could I learn how to do them?

Crypto is not about breaking in, but breaking codes. It is mostly a bunch of maths.

http://www.amazon.com/Cryptography-Engineering-Principles-Pr...

Re: The Bitcoin Piñata

#108

Post by mtrimpe »

ukigumo wrote: post #102
mtrimpe wrote: post #100

Earlier quoted context omitted.

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.

Ok, but that would only be true if I was going to spin up a new vm to join the load group / cluster but even then no one would do that unless behind a reverse proxy / waf load balancer so the attack vector angle is covered. I'm not saying MirageOS doesn't sound neat, I'm just not yet convinced it has a general purpose use case.

Due to the startup time your average server would, in practice, still need to run an SSH server for remote administration which is a vector for attack. A MirageOS server you would instead just tear down and start a new version of.

A WAF also still passes through HTTP requests which hit Apache/nginx which calls out into the OS and altogether that give a significant surface area for vulnerability (think e.g. shellshock and ENV variables.)

I also don't think anybody says that MirageOS is ready for the general purpose use case; it's very much specific experimental tooling for (currently) really niche cases.

Unikernels do have a ton of future potential though ....

Re: The Bitcoin Piñata

#109

Post by un1xl0ser »

comex wrote: post #92
ricket wrote: post #91

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…

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 poss…

A weak RNG may create an opportunity for successful cryptanalysis. This can especially be a problems on virtual hardware/platforms that don't have a mechanism for keeping a good random seed, and have predictable hardware events, et cetera.

Re: The Bitcoin Piñata

#110

Post by ukigumo »

amirmc wrote: post #105
ukigumo wrote: post #104

Earlier quoted context omitted.

Are you sure? I'm usually very careful with my usage of figures of speech but I'm no language major so maybe I should clarify that I meant that I could see edge cases but not a general purpose one. Did this clarify my point or in any other way contribute to your undestanding?

MirageOS is useful for creating single-purpose appliances. That fits well with how the cloud is used today (where you typically end up with one service/app per VM anyway). The autoscaling piece is only one aspect and is only in the early stages, so you shouldn't dwell on it. The overview page and the ASPLOS paper (linked upthread) and the ACM article [1] will help explain the benefits and trade-offs of the unikernel…

Thank you, I'm going to read through those carefully.
Post reply on HN