Потому что, зачастую мы не можем выразить все свои эмоции не употребляя мата. И иногда мат - просто идеально подходит в той или иной ситуации. Но люди создали какой то стереотип - что матом ругаться не красиво. По мне так это обычное слово.

Я по знаку зодиака - стрелец. И у меня много родственников скорпионов. Наше общение просто не выносимо) Так как и стрелец не уступит и скорпион тоже. Очень тяжелые характеры.

Лично я - ярый футбольный фанат, у которого есть свой любимый клуб, за который я болею достаточно долго. Но я не могу выбрать какой то один вид спорта, футбол конечно очень хорош, но и теннис я думаю не сильно отстает зрелищности.

Как говорит мой знакомый, из безвыходной ситуации 2 выхода) первый - в петлю, второй - решить проблему любой ценой). Так что, дорогие товарищи - в путь, решать проблемы!)

Мясо, мясо и ещё раз мясо)) шашлыки, запеченая курица с картошкой, мясо по французски и пиво))

Я - фанат эпл, да - дорого, и многие говорят понты и все такое. Но я лучше переплачу и буду пользоваться качественным гаджетом чем экономит и мучаться с каким нибудь г.. да простят меня Самсунг и иже с ними) хотя каждый для себя выбирает

Фу, фу и Еще раз фу! Абсолютно не нравится, запах ужасный да ещё и некоторые умудряются с детьми ходить и курить. Просто отвратительно

Семья конечно же. А потом уже все остальное, когда знаешь что тебя любят и ждут, то все по плечу. Ещё конечно путешествия, новая информация, развитие

Блин, странная тема))люблю, но отношений не хочу) наверное никак не разлюбишь) если только специально не выдавливать все мысли о ней. А вообще лучший способ - не сталкиваться с ней и поменять(если можно) работу)

А я люблю все праздники)) есть шикарная возможность уделить время своей семье, подарить подарки, да и просто побыть всем вместе и пообщаться. Это сплачивает всех, а что за праздник(кроме др конечно)) и неважно)

прикольное и действительно перспективное устройство. Лишь бы некоторые не приняли это за панацею и перестали ходить к врачам, надеясь только на него. А как небольшая альтернатива - вполне имеет место быть

Doesn't zlib already build and work in C++ ? Did you want a C++ -compliant wrapper around zlib or a full recode of zlib into C++ ?

Would C++11 be a more appropriate target?

I've done an Objective-C wrapper around zlib before, see https://github.com/pixelglow/zipzap .

Cheers
Glen Low
Pixelglow Software

I'm only a regular programmer with a math background, hence the interest in cryptography. I once worked on a font DRM scheme which used crypto, and I'm currently working on an Australian bitcoin exchange that will feature crypto as well. The rest of it is just google  .


http://www.openssl.org/docs/crypto/EVP_BytesToKey.html seems to indicate you should move to PKCS#5 v2.0, which is PBKDF2.


Indeed, there is the PKCS5_PBKDF2_HMAC_SHA1 function in OpenSSL. I just submitted a patch to node.js to incorporate this: https://github.com/joyent/node/pull/1491


RFC 2104 (http://tools.ietf.org/html/rfc2104) seems to think that any half-decent cryptohash will do, even MD5 (!), since HMAC has a secret key which greatly expands the amount of computation you need to do to break it. I suggested HMAC-SHA1 since the PBKDF2 in OpenSSL is based on it (symmetry!), it seems to be used often enough (newer schemes have less cryptanalysis done, could have flaws you don't anticipate esp. used in tandem like with HMAC) and produces a smaller output.


Indeed. Simple schemes work best sometimes in crypto since less can go wrong. As for using XOR, check out wikipedia's article on Vernam ciphers: http://en.wikipedia.org/wiki/Vernam_cipher. TL;DR: so long as the key is truly random, as large as the plaintext and never reused in whole or part, it should be unbreakable. Obviously we can't get the first one 100% since we're starting with a human password and PBKDF2 I think doesn't make any guarantees about the randomness of the result. The second requirement is true. The last requirement should be ensured by the use of random salts.

Does bitcoin encryption use AES with a single key on the entire wallet, or AES on individual keys (without an IV or starting at the same point)? The former is pretty sensible. The latter can be dangerous since you are effectively reusing the key.

Interesting, although your layering/composing of different cryptographic schemes may come back to bite you.

As I see it, you want to encrypt the password and also verify that the encrypted bits are unchanged. Here's a slight modification of the above:

privkey = 32-byte EC private key, big-endian form
salt = 4-byte random salt value
symkey = PBKDF2(HMAC-SHA1, password, salt, 4096, 64)
cryptedprivkey = (privkey XOR symkey[0:32])
pwcheck = HMAC-SHA1(symkey[33:64],cryptedprivkey)
protkey = cryptedprivkey | pwcheck | salt

• You should use the more recent PBKDF2 (http://www.di-mgt.com.au/cryptoKDFs.html), which allows you to produce arbitrary length keys. In this case we're generating a 64-byte length key, half of which we'll use for encryption and the other half for authentication.
• Next we encrypt the privkey with half the symkey by XOR'ing them together, a simple stream cipher. This avoids the use of AES in client code (slow in Javascript?, missing an initialization vector, plaintext length < AES block size of 128 bits) and should be pretty safe. Stream ciphers like RC4 are simply a random keystream XOR with the plaintext and are difficult to break, provided the random keystream is truly unpredictable and you never repeat the key. The trouble with stream ciphers then manifests when you have a large enough chunk of data to encode, then without a proper CPRNG like RC4 the keystream may repeat etc. and thus block ciphers under CBC become useful. Since we have a 32-byte private key and a 32-byte symkey to XOR together, this should not be the issue.
• We then use a MAC, specifically a HMAC-SHA1, to act as the password check against modification. We use the second half of the symkey as the secret. HMAC's are particularly designed for message authentication.

Alternatively (safer/more paranoid) you could use two salts to produce two 32-byte keys, one for the encryption, one for the authentication.

Interesting idea.

If you don't know the private keys, how do you get the server to send out the payments on behalf of your clients? Are you using a custom bitcoind or the regular one? Even if you're using a custom bitcoind, at some stage your server must in possession of the private keys in order to sign the outgoing transaction? Or are your transactions even signed on the client side and passed back to your server somehow to be sent out?

I'm a big fan of open development, but not always open source. In open development, you release early and often and take people's feedback all the time. In open source, you expose your source which may not result in a commercially viable enterprise, and you often don't get many contributions until the project is big enough and/or the code is easy enough to get into.

I intend to make some money through minimal fees. Hey I gotta feed the wife and kids.

Is there any interest out there in open-sourcing or even licensing this? Is this different enough from Intersango etc.?

Yes, exactly. Most of the international exchanges have significant deposit fees and/or long deposit times. By siting this purely in Australia, I hope to overcome these issues.

Oh and if you want to donate real bitcoins to the cause, my address is: 1KPsqA8eRzTAeZXyWuL2NxdgYxv5PW8HVb

What is it?

I'm working on a new Australian bitcoin exchange, on both the business and technical ends. There will be a spiffy new website front-end that talks to a back-end via a RESTful JSON API. I'm aiming for fast transfer turnaround, an architecture that makes sense for robust and secure service, and a super interactive and easy-to-use front end.

Currently I've only got part of the back-end ready for testing.

How can you help?

I need some testers who are comfortable with using curl and friends on the command-line to give the test web service a good bashing. In particular, I need to know whether the accounts, adding/withdrawing funds, orders and trades work the way you expect. You don't have to be an Australian, but it would help since this market is for you. You'll also need some testnet bitcoins handy (which you can get from the faucet).

How do I start?

The test exchange is currently hosted in an AWS micro instance here: ec2-50-16-82-86.compute-1.amazonaws.com. Each new account starts with 5000 AUD (fake of course) and 0 BTC, but you can add or withdraw testnet bitcoins to the account. The fees are set at arbitrary percentages as well.

Public API
These are actions you can take without authenticating. Since this is a RESTful API, use the curl -X option to set the method (POST, GET etc.) and use the URL listed.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/

• POST: To create a new account for yourself, POST your account details as a JSON object e.g. {"name":"charlesxavier", "password":"professorx","email":"charles@xmen.com","withdrawBitcoinAddress":"AABBCCDDEE","withdrawDirectCreditBSB":"000-000","withdrawDirectCreditAccount":"0001","withdrawDirectCreditTitle":"C. Xavier"}. If there any errors, you should get an error message telling you what went wrong, otherwise it will reply with a 201 Created response and the Location: header tells you where the account was created.

http://ec2-50-16-82-86.compute-1.amazonaws.com/trade/

• GET: This lists all the trades up to a week old in the system and should conform to BitcoinCharts.

http://ec2-50-16-82-86.compute-1.amazonaws.com/order/

• GET: This lists entire order book and should conform to BitcoinCharts.

Account API
These are actions you can only take when authenticated. Use Basic authentication with the name and password you gave when you registered the account above.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/

• GET: retrieve your account details, including details added by the system. Use your own account name above of course.
• PUT: change account details (not yet implemented).
• DELETE: delete the account (not yet implemented).

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/addBitcoin/

• GET: list any bitcoins you have added into your account. Use the addBitcoinAddress given when you retrieve your account details to add bitcoins to your account. Note we're testing with testnet bitcoins only and will wait for 6 confirmations before entering the system.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/withdrawBitcoin/

• GET: list any bitcoins you have withdrawn from your account.
• POST: to withdraw bitcoins, POST the details as a JSON object e.g. {"btcAmount":10}. This uses the withdrawBitcoinAddress given when you set up your account details to withdraw bitcoins. Note we're testing with testnet bitcoins only. If successful you'll get a 201 Created response with Location: header set to where the withdrawal is.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/withdrawBitcoin/23/

• GET: retrieve details of a particular withdrawal.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/bid/

• GET: list any outstanding bids you have made in the system.
• POST: to create a new bid, POST the bid details as a JSON object e.g. {"amount":100, "bidPrice":10.0}. If successful you should get a 201 Created response with Location of the created bid.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/bid/23/

• GET: retrieve the details of a particular bid.
• DELETE: withdraw the bid (not yet implemented).

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/bid/23/trade/

• GET: list any trades that were made against your particular bid.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/bid/23/trade/45/

• GET: retrieve the details of a particular bid trade.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/ask/

• GET: list any outstanding asks you have made in the system.
• POST: to create a new ask, POST the bid details as a JSON object e.g. {"amount":100, "askPrice":10.0}. If successful you should get a 201 Created response with Location of the created ask.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/ask/23/

• GET: retrieve the details of a particular ask.
• DELETE: withdraw the ask (not yet implemented).

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/ask/23/trade/

• GET: list any trades that were made against your particular ask.

http://ec2-50-16-82-86.compute-1.amazonaws.com/account/charlesxavier/ask/23/trade/45/

• GET: retrieve the details of a particular ask trade.

Thanks for all your help and feedback!

For closure:

You can build a bitcoind (headless bitcoin) on a Mac. The build instructions are not with the usual binary distribution but you can grab them off the github repository for bitcoin. The minimal dependencies are: boost (from boost.org) and Berkeley DB (from the freshmeat.net project), you (apparently) can use libssl and libcrypto from the system.

bitcoind appears to run undaemonized, so it should be suitable for a launchd script. But I haven't tested this configuration yet.

Cheers,
G.