00:44:47WOODMAN:http://www.cryptocoinsnews.com/2014/03/05/linux-openssl-security/#comments
00:53:06gmaxwell:WOODMAN: why are you linking us to that?
00:53:56WOODMAN:alt ideas it says
00:54:26gmaxwell:WOODMAN: you want #litecoin
00:54:36WOODMAN:article is about bitcoin
00:55:01gmaxwell:that article is confused, I am not aware of any bitcoin article that uses gnutls.
00:55:04WOODMAN:litecoin is related as its built on same program
00:55:16WOODMAN:hmmmm good point
00:55:28WOODMAN:why would they not be bound by GNU license agreement?
00:55:47WOODMAN:same free software license agreement
00:55:52WOODMAN:is it not?
00:55:58WOODMAN:id say its highly relative
00:56:07WOODMAN:read my posts in comments
00:56:10gmaxwell:It is not relevant.
00:56:33gmaxwell:nanotube: Hows that quiz thing progressing?
00:56:38midnightmagic:lol
00:57:07gmaxwell:WOODMAN: you might also note the second sentence of the article.
00:58:09WOODMAN:yah and im eluding that litecoin has problem with wallet
00:58:26gmaxwell:Which is why you should be asking in #litecoin.
00:58:31WOODMAN:more to this story at 11
00:58:38WOODMAN:hey bud i just posted
00:58:45WOODMAN:like the paperboy leaving paper at the door
00:58:53WOODMAN:dont worry ill come back and ask for a tip later
01:39:43gmaxwell:andytoshi: you sure about that blind comment? I was thinking that rather you'd take the private key and a random value and use that to derrive the new private key and blinding factor.
01:39:55gmaxwell:andytoshi: since unlike a real blind signature nothing is really blind.
01:42:43andytoshi:gmaxwell: pretty sure, give me a minute
01:43:05gmaxwell:andytoshi: I am bad and haven't opened up his paper and worked through any of the math.
01:43:38nsh:math is largely propaganda anyway
01:43:44andytoshi::P
01:44:07andytoshi:so, the way his protocol works is that the blindsigner starts by choosing two random values and sending keys based on these to the message holder
01:44:27andytoshi:the message holder then tweaks the keys, basically, but without solving DL she can't tweak them to get a desired key
01:45:58gmaxwell:feh, you're going to make me open the paper. ... you understand that my goal there is to only end up in the state where every EC multiply has been blinded by a random factor. right?
01:46:28andytoshi:yeah, i'll think about whether that's possible. but oleganza's paper definitely can't do it for you
01:46:28gmaxwell:so that someone who can learn what number is being multiplied by a side channel in the multiply learns nothing useful.
01:47:41andytoshi:yeah, i got that, it's a usecase i hadn't considered for 'blind sigs' in which the blindsigner doesn't know the key
01:49:02gmaxwell:e.g. G*s = G*(s-a+a) = g*(s-a) + g*(a) and a is different every time.
01:49:22andytoshi:i feel like i got something like this back when i was trying to get signer-visible keys from a variant of oleganza's scheme, i'll spend a few minutes trying to recreate it
01:56:58davvblack:Do you have a link to that paper?
01:57:27andytoshi:davvblack: http://oleganza.com/blind-ecdsa-draft-v2.pdf
02:01:19phantomcircuit:Luke-Jr, did you get a ride?
02:04:37andytoshi:i left about 90 minutes ago, he was still there..but every single mining company knew him so i think he'll be able to find someone
02:05:21phantomcircuit:andytoshi, yeah im sure he can get a ride with someone from cointerra
02:05:35phantomcircuit:just making sure he doesn't get stuck out there
02:12:07andytoshi:gmaxwell: nope, i don't think i can tweak oleganza's scheme to do what you want. maybe i can do it from scratch tho
02:12:28andytoshi:generally with ecdsa the stupid nonce insists on being known by all parties, then ofc everybody can see the key..
03:18:59zzyzx:zzyzx
03:53:54jtimon:is the question I just asked on #bitcoin-dev stupid or irrelevant? would it be more relevant here (next step is to replace pow with a centralized signature)?
03:59:06gmaxwell:jtimon: ... you haven't said anything there.
03:59:20gmaxwell:are you not registered with freenode? :P
04:00:52jtimon:no, I'm not, but I guess I will to answer that quiz
04:01:16jtimon:maybe I should do that now
04:01:46jtimon:are comments from non registered people automatically ignored or something?
04:02:06gmaxwell:bitcoin-dev is +r so you can only talk in there if you're registered. Your client should tell you this but I think some don't or only do subtly.
04:04:11jtimon:I see, thank you, last time I wasn't ignored there was that bdb fork night where I suggested using jgarzik's bittorrent to re-download the chain. I don't talk there very often so I didn't realized that
04:04:22jtimon:I'll register now then
04:12:22jtimon:jtimon is now known as jtimon2
04:13:20jtimon2:jtimon2 is now known as jtimon
04:16:29just[dead]:just[dead] is now known as justanotheruser
04:30:16ageis_:ageis_ is now known as ageis
05:32:56justanotheruser:justanotheruser is now known as just[dead]
06:08:34just[dead]:just[dead] is now known as justanotheruser
06:10:26michagogo|cloud:jtimon: uh, a year ago?
07:01:27jtimon:michagogo|cloud yep that's the last time I remember being answered, maybe there was a more recent time, I can't remember since, as said I don't use that channel much, mostly lurk, when was that registration requirement put on?
07:06:58michagogo|cloud:Idk
07:07:13michagogo|cloud:It's been like that for a while, I think
07:08:32wumpus:yes for a pretty long while, I was stung by it once too, didn't see the messages that my messages were rejected... unfortunately it's necessary because of all the spam and scam in bitcoin-releated channels
07:12:26gmaxwell:the worst is when chanserv goes away and I can't talk there at all.
07:14:07michagogo|cloud:gmaxwell: chanserv?
07:14:16gmaxwell:er nickserv
07:14:22michagogo|cloud:Ah
07:14:55michagogo|cloud:(Though I'm pretty sure one won't be dead without the other, now that I think about it)
07:15:24michagogo|cloud:They're both part of Atheme
11:39:02nsh::( satoshi
12:01:50MoALTz:poor guy - regardless of whether he is actually _the_ satoshi
12:04:52stonecoldpat:what you guys on about?
12:06:08MoALTz:as posted in #bitcoin earlier: http://mag.newsweek.com/2014/03/14/bitcoin-satoshi-nakamoto.html
14:25:52HM:poor guy
14:38:00helo:hopefully he doesn't have to move or sell is car
14:46:38HM:It amuses me how the article quotes "disk space" and says how it hasn't been an issue since the last millennium
14:52:06stonecoldpat:i used it in a sentence couple minutes ago
14:52:28stonecoldpat:admin gave me 10gb on a virtual machine :/
14:52:46stonecoldpat:cant store bitcoin on that
14:57:22HM:how big is the blockchain these days?
15:00:25epscy:nearly 20gb
15:01:51stonecoldpat:its size is ballooning nowadays
15:03:52HM:that's not as bad as i expected
15:05:19HM:stonecoldpat, i've given up on VMs. I have a small family of little atom based dedi's... you can get a 500GB atom server for like €9/mo
15:05:59HM:i prefer to have a handful of little servers than 1 big momma so i can experiment more
15:07:03stonecoldpat:might have a look into that, atom server is just a combination of smaller servers put together ?
15:08:04HM:Intel Atom CPU
15:08:13stonecoldpat:ahh ok, thats shows my ignorance in hardware
15:10:32HM:I'm not sure how such a weak cpu would cope syncing the blockchain
15:11:03HM:i might give it a go sometime, or maybe do it locally and rsync it
15:26:39nsh:so who wants to write a brief press release on reprehensible journalistic practice?
15:29:48nsh:meanwhile:
15:29:49nsh:--
15:29:49nsh:Abstract. We apply the FLUSH+RELOAD side-channel attack based on cache hits/misses to extract a small amount of data from OpenSSL ECDSA signature requests. We then apply a “standard” lattice technique to extract the private key, but unlike previous attacks we are able to make use of the side-channel information from almost all of the observed executions. This means we obtain private key recovery by observing a relatively small number of executions, a
15:29:50nsh:nd by expending a relatively small amount of post-processing via lattice reduction.
15:29:50nsh:We demonstrate our analysis via experiments using the curve secp256k1 used in the Bitcoin protocol. In particular we show that with as little as 200 signatures we are able to achieve a reasonable level of success in recovering the secret key for a 256-bit curve. This is significantly better than prior methods of applying lattice reduction techqniques to similar side channel information.
15:30:00nsh:-- http://eprint.iacr.org/2014/161.pdf
15:30:06nsh:(via: http://arstechnica.com/security/2014/03/scientist-devised-crypto-attack-could-one-day-steal-secret-bitcoin-keys/ )
15:31:55super3:bitcoin is hacked right. i should sell everything?
15:34:50nsh:yes, to me, at firesale prices
15:35:03nsh:in fact, just sign over power of attorney; it'll save us time
15:39:26Emcy:super3 no shutup
15:39:42super3:he he
15:39:57HM:are cache hit/misses transparent to virtual machines or do context switches between VMs effectively flush caches?
15:40:10HM:I bet there are a lot of people out there with private keys on VMs
15:40:24nsh:good question
15:40:27nsh:(s)
15:40:35super3:im ashamed of the amount of coin i've made from people panic selling
15:41:23nsh:you know what they say in that old proverb about he who profits from catastrophes, but can't afford apostrophes?
15:41:36nsh:neither do i, but shut up anyway.
15:43:26super3:HM, storing wallets on VMs are probably a semi-bad idea(for the paranoid) in any case unless you control the hardware
15:43:42super3:im curious if VMs can make use of TPM, and perhaps solve that problem
15:45:36HM:Yes of course, but people will nethertheless do it
15:51:32maaku:super3: hot wallets
15:52:09maaku:TPM probably makes the timing attacks worse, since it's slower hardware
15:52:47super3:maaku, explain. I don't know too much about TPM.
15:54:32HM:a TPM can't do ECDSA signing, so its irrelevant
15:58:36maaku:HM: the trust zone can, which is sometimes what people mean...
15:58:59HM:trust zone?
15:59:59helo:is the attack observing while 200 arbitrary signatures are calculated?
16:00:25helo:or do the signatures need to conform to some parameters?
16:00:33helo:(signed data, that is)
16:00:39HM:i haven't read it
16:01:12HM:i saw a cool presentation about timing intel cpus during microcode updates
16:01:28HM:the authors were able to determine the construction of the encryption and MAC used by Intel for their microcode updates
16:01:36helo:as far as VMs, i think the more common case is the attacker having control of the dirty VM that has no private keys, with the host OS holding the keys
16:02:13HM:(even though its performed in hardware and not documented)
16:02:44helo:that is quite some divination
16:04:11HM:http://inertiawar.com/microcode/
16:04:33HM:some of its actually binary reverse engineering, but its very cool
16:05:05HM:even determined intel moved from SHA1 to SHA2
16:34:30gavinandresen:gavinandresen has left #bitcoin-wizards
16:40:40justanotheruser:justanotheruser is now known as just[dead]
17:53:20mr_burde_:mr_burde_ is now known as mr_burdell_
18:02:57mr_burdell_:mr_burdell_ is now known as mr_burdell
19:57:17wallet421:wallet421 is now known as wallet42
21:34:51ghtdak:ghtdak has left #bitcoin-wizards
22:24:59[\\\]:[\\\] is now known as pirateat40
22:27:13pirateat40:pirateat40 is now known as [\\\]
23:21:33just[dead]:just[dead] is now known as justanotheruser
23:37:03justanotheruser:justanotheruser is now known as just[dead]
23:55:46just[dead]:just[dead] is now known as justanotheruser