Quantum, CS, Misc
I have created a repository that has an OPML file containing an assorted list of different blogs that are worth following.
Majority of the blogs are related to Cryptography, CTF write-ups, Mathematics and a bit of Physics (Quantum computation, cryptography).
Just import the OPML file to your favourite RSS reader and it will work out-of-box. It might be the case that some of the blogs are no longer maintained actively by the author(s).
Contributions to the list are highly welcomed 🙂
This post describes how to call Bitcoin information using simple Python scripts. The bitcoin client has a powerful API and RPC interface that can be easily called in practically any programming language one can think about.
Python is common and easy to understand scripting language that is extremely useful for automating complex tasks, especially for the bitcoin based tasks. This makes it ideal language to jump in playing with bitcoin transactions or the blockchain based applications.
Python supports byte sequences and large integers which makes it good fit for bitcoin operations. The bitcoin client on the other hand, is highly robust.
The RPC interface in the client allows easy retrieval of information such as the network, peer connectivity, wallet related operations, signing and other low-level information such as raw transaction constructions!
This post already assumes that user has the bitcoin client (`bitcoind`) installed and setup. First step is to run the `bitcoind` as a server using the following command:
$ bitcoind -daemon -printtoconsole
This will start `bitcoind` as a client that connects to other nodes in the bitcoin network and also as a local server that allows use of RPC calls. To make use of the RPC capabilities it is must to have RPC username and password set up in the bitcoin configuration file. The bitcoin configuration file `bitcoin.conf` is by default in ~/.bitcoin/bitcoin.conf , which if configured before running bitcoind will continue with the process of connecting to other nodes within the bitcoin network, synchronizing the blockchain along with listening to local RPC calls.
Note: It is possible to run `bitcoind` as a daemon (background process) thus reducing the workplace cluster that would otherwise spawn during the experimentation.
It is highly recommended that experimenting with RPC be conducted over either the `regtest` or the `testnet` to avoid mishaps with valid bitcoins. To run the bitcoind in either regtest or testnet mode, pass on the mode as argument for bitcoind as shown below:
$ bitcoind -[testnet=1/regtest] -daemon -printtoconsole
In earlier versions of bitcoind it was possible to directly execute the RPC calls by passing the calls as arguments to bitcoind. In current versions, this method has been deprecated and now it is required to pass these arguments to the bitcoin-cli. For example, with bitcoin configuration set and bitcoin server running, it is possible to do the following:
| $ bitcoin-cli -testnet getblockhash 7777 | |
| 0000000007b52c4ff25443ab5a07cea530bb6981aad956116239e9c060bda368 | |
| $ bitcoin-cli -testnet getblock 0000000007b52c4ff25443ab5a07cea530bb6981aad956116239e9c060bda368 | |
| { | |
| "hash": "0000000007b52c4ff25443ab5a07cea530bb6981aad956116239e9c060bda368", | |
| "confirmations": 1118426, | |
| "strippedsize": 191, | |
| "size": 191, | |
| "weight": 764, | |
| "height": 7777, | |
| "version": 1, | |
| "versionHex": "00000001", | |
| "merkleroot": "064d68e9b8eb27b6db3a1f993cf8c1fefd4acc86721e30a062abac17de3b2638", | |
| "tx": [ | |
| "064d68e9b8eb27b6db3a1f993cf8c1fefd4acc86721e30a062abac17de3b2638" | |
| ], | |
| "time": 1338180890, | |
| "mediantime": 1338180889, | |
| "nonce": 2057802261, | |
| "bits": "1c0ffff0", | |
| "difficulty": 16, | |
| "chainwork": "0000000000000000000000000000000000000000000000000000995099509950", | |
| "previousblockhash": "00000000010876fecdc6f59b34a95ba790e5140ef694986e4b7ac9aadde3415b", | |
| "nextblockhash": "000000000a14868100bb1cb9cbf25fa853df56c56392556ba66aecc6de0af641" | |
| } |
When the bitciond is executed in server mode, it setups a local http server that listens for requests, decodes the method name and the parameters mentioned in these requests and encodes the results as response to the http request. These encoding and decoding nothing than encapsulating as a JSON data.
From the other side, the bitcoin-cli looks up the RPC connection information from the bitcoin.conf, creates a http connection to the server, encodes the method name and parameters specified as JSON, sends a specifically formatted http request that includes the JSON. Finally, upon receipt of the http response, it decodes the JSON and outputs it for the user.
There are numerous libraries that can be used for connecting the bitcoin-rpc with Python. For the sake of simplicity, we use the requests library for Python. By working with python we simply pass on the arguments that would otherwise be passed via the bitcoin-cli using Python.
An example script that queries the earlier example is below:
https://gist.github.com/50226b8aca960dfb49d19aa688d5700b
If the packages are installed correctly then it should display output like the following:
| {u'merkleroot': u'064d68e9b8eb27b6db3a1f993cf8c1fefd4acc86721e30a062abac17de3b2638', | |
| u'nonce': 2057802261, u'previousblockhash': u'00000000010876fecdc6f59b34a95ba790e5140ef694986e4b7ac9aadde3415b', | |
| u'hash': u'0000000007b52c4ff25443ab5a07cea530bb6981aad956116239e9c060bda368', u'version': 1, u'weight': 764, | |
| u'chainwork': u'0000000000000000000000000000000000000000000000000000995099509950', u'mediantime': 1338180889, | |
| u'height': 7777, u'difficulty': 16, u'nextblockhash': u'000000000a14868100bb1cb9cbf25fa853df56c56392556ba66aecc6de0af641', | |
| u'confirmations': 1118429, u'time': 1338180890, u'versionHex': u'00000001', u'strippedsize': 191, | |
| u'tx': [u'064d68e9b8eb27b6db3a1f993cf8c1fefd4acc86721e30a062abac17de3b2638'], u'bits': u'1c0ffff0', u'size': 191} |
Note: Before executing the script you would need to change the rpcuser, rpcpassword and rpcport in the script to reflect the parameters defined in the bitcoin.conf file.
It is worth noting that the output data is returned in the form of Python dictionaries and lists which can be directly referred in other Python scripts without requiring any further processing.
It is useful to have errors and exceptions in the scripts above to make it easier for debugging. To do so, we encapsulate the our functionalities as a python class:
| from __future__ import print_function | |
| import time, requests, json | |
| class RPCHost(object): | |
| def __init__(self, url): | |
| self._session = requests.Session() | |
| self._url = url | |
| self._headers = {'content-type': 'application/json'} | |
| def call(self, rpcMethod, *params): | |
| payload = json.dumps({"method": rpcMethod, "params": list(params), "jsonrpc": "2.0"}) | |
| tries = 5 | |
| hadConnectionFailures = False | |
| while True: | |
| try: | |
| response = self._session.post(self._url, headers=self._headers, data=payload) | |
| except requests.exceptions.ConnectionError: | |
| tries -= 1 | |
| if tries == 0: | |
| raise Exception('Failed to connect for remote procedure call.') | |
| hadFailedConnections = True | |
| print("Couldn't connect for remote procedure call, will sleep for five seconds and then try again ({} more tries)".format(tries)) | |
| time.sleep(10) | |
| else: | |
| if hadConnectionFailures: | |
| print('Connected for remote procedure call after retry.') | |
| break | |
| if not response.status_code in (200, 500): | |
| raise Exception('RPC connection failure: ' + str(response.status_code) + ' ' + response.reason) | |
| responseJSON = response.json() | |
| if 'error' in responseJSON and responseJSON['error'] != None: | |
| raise Exception('Error in RPC call: ' + str(responseJSON['error'])) | |
| return responseJSON['result'] |
This script can be easily used like following:
| # Default port for the bitcoin testnet is 18332 | |
| # The port number depends on the one writtein the bitcoin.conf file | |
| rpcPort = 18555 | |
| # The RPC username and RPC password MUST match the one in your bitcoin.conf file | |
| rpcUser = 'Alice' | |
| rpcPassword = 'test' | |
| #Accessing the RPC local server | |
| serverURL = 'http://' + rpcUser + ':' + rpcPassword + '@localhost:' + str(rpcPort) | |
| #Using the class defined in the bitcoin_rpc_class.py | |
| host = RPCHost(serverURL) | |
| hash = host.call('getblockhash', 7777) | |
| print (hash) | |
| block = host.call('getblock', hash) | |
| coin = block['tx'][0] | |
| test = host.call('listreceivedbyaddress', 0, True) | |
| print (test) |
There are a couple of wrapper libraries in the wild that adds the actual functions for each of the RPC methods (e.g. bitcoin-python). Personally, I like the to have a simple RPCHost class as defined earlier to keep it simple and avoid dependencies on third-party libraries. This is especially helpful if you intend to have complex RPC call chains. Furthermore, creating your own RPCHost class makes it easier to implement further bitcoin based ‘applications’ such as the Lightning Network.
The popularity (or unpopularity) of bitcoin lead to rise of many different alternative cryptocurrencies, bunched under the term Altcoins. These altcoins in principle is the fork from the bitcoin code which includes the RPC setup which means one can use the same RPC code with almost all of the altcoins.
For example, the Litecoin’s RPC capabilities can be access just by changing the port to 9332 in the same script; the Dogecoin at 22555, etc.
The possibilities of the ‘shared’ RPC base are near endless 😀
Making calls to RPC bitcoind is trivial! The applications that can developed using such calls are enormous. In future post, I will be sharing more of tricks for optimizing the RPC calls using Python scripts that I have learned in my own RPC adventures, which will include RPC calls for Lightning Network.
1st April is the day on which no information can be easily taken as fact and is also the day where pranking or fooling anyone tends to bring laughter rather than angry stares.
Yesterday, some of my friends were commenting how many people from different science streams have played elegant pranks on their respective communities and surprisingly (or unsurprisingly) they claimed that Cryptographers have never played any good April fool. Cryptographers have had their own share of April Fool incidents, maybe not as geeky as Google’s annual April fool (I loved the Quantum code testing*); but Crypto April fools have a certain stroke of brilliance in them that cannot be compared to others.
This year PHC (Password Hashing Competition) mailed the following to everyone, sharing this since not many seem to be aware:
After over two years of in-depth analysis and careful deliberation, today the panel is pleased to announce that LM Hash has been unanimously selected as the winner of the PHC. To many panel members, the choice was obvious.
Selection criteria includes the following, in no particular order:
– LM Hash leverages the well-studied and proven DES block cipher.
– Most users only select passwords that are 6 – 8 characters long, so LM Hash’s 14-character limitation is more than reasonable for the majority of use cases.
– LM Hash is not case-sensitive, reducing the number of password reset requests and Help Desk tickets that result from users not remembering their precise passwords.
– Most LM Hash values have already been pre-computed and made publicly available, reducing load on authentication servers.
– LM Hash does not require the use of salt, which aligns with the American Heart Association’s guidelines for a low-sodium diet.
– LM Hash requires little energy to compute, thereby contributing to environment-friendly authentication systems.
As a Microsoft employee, Marsh Ray was the most vocal advocate for LM Hash, noting that Microsoft, IBM, and 3Com have had support for LM Hash since 1988. Alexander Peslyak added that LM Hash is the ideal PHC winner since it’s already well-supported in John the Ripper. Jeremi Gosney and Jens Steube were quick to agree, noting that LM Hash has all of the qualities they desire in a password hash.
Comparing LM Hash to other PHC finalists:
– Unlike LM Hash, Argon and Catena are resistant to TMTO, wasting valuable CPU cycles.
– Battcrypt uses Blowfish, which was developed by that charlatan Bruce Schneier. LM Hash uses DES, which was developed by IBM and the NSA. Which do you trust more?
– Lyra2 relies on a sponge for security, which is by definition full of holes. LM Hash relies on a block cipher. Blocks don’t have holes.
– Pufferfish encrypts the palindrome “Drab as a fool, aloof as a bard.” LM Hash encrypts the string “kgs!@#$%”, saving the user 24 bytes.
– LM Hash is far simpler than yescrypt! It can be described in one line, whereas yescrypt can’t even be described in one book.
– Unlike Makwa, LM Hash is post-quantum!
– Parallel was designed by Steve Thomas, who you can’t trust to hash your password. LM Hash wasn’t designed by Steve but by trusted Microsoft experts.
Being the choice of foremost thought leaders in the field, LM Hash is already a success:
– LM Hash will appear in the next Gartner Magic Quadrant for state-of-the-art password hashing.
– Academic researchers have started applying for grants in order to investigate security proofs of LM Hash in the related-password model under relaxed misuse-resistance assumptions. Leading researchers already expect breakthrough indifferentiability proofs in the ideal cipher model.
– A new secure messaging application will generate one-time-pad masks from user passwords using LM Hash, promising higher security than legacy solutions such as TextSecure.
Rating in terms of other April fool stuffs around, I would easily rather this as first for sure. And since this post is about April fool another good prank played by a Professor on his student can be watched below:
*Google announced that it had successfully modeled all possible states of software using quantum superposition techniques.
Long time since last post; but the reasons as always being that I am busy trying to get in rhythm, learning to cook efficiently 😛 and so on..
Recently Australia had its first experiment with e-voting, which while good doesn’t exactly fits the ideal description of what is expected from e-voting schemes. I myself am not a firm believer in the e-voting systems. The main problems that are not answered, which according to me as the bases of any voting scheme, are the properties of Verification, Privacy and Classification
Example: In a classical voting system, a voter puts a vote on paper, folds it and drops it inside the designated box. In this case, a voter knows for sure that his/her vote is being considered and would be counted in the final outcome. Furthermore, the voter can also be assured that the vote cased is a real and valid vote. This verifiability property seems to be missing from e-votings. Although it is worth noting that many protocols do offer this property where the voter can check his/her vote against final tally. (Estonian voting protocols are prime example)
Some protocols do exist that allows for the voters to re-cast votes and the last vote casted is considered as a valid one. But that does not exactly provide a optimal solution.
Example: (Valid for India) Whenever a voter wants to decline voting due to no suitable candidate standing for the election, then he has two options:
This option of invalidating the vote (and remaining anonymous), besides not casting the vote, seems to be missing in e-voting. Furthermore, current e-voting systems are also not being ‘democratic’, so to speak.
* Theoretical in a sense that there are lots of realistic stuffs that do infact influence the voting outcomes (Bribing, fake-voting, vote-for-money…)
Now that I have got pretty much settled in routine schedule in Luxembourg, I decided to post some photo here.
For everyone playing around with Crypto there are certainly moments where the developed and implemented algorithm does just the opposite of what is expected; which leads to the code thrown off in some dark corner of the hard-disk. If this is same case with you, now is the good time to get all those codes that out because there is a new crypto competition!
The Underhanded Crypto Contest is a competition to write or modify crypto code that appears to be secure, but actually does something evil. For example:
* A password hashing library that always accepts the password “monkey.”
* A MAC algorithm that can be broken if you know some fixed secret key.
* Something that leaks the key through a reliable side channel, padding, IV, etc.
* A user interface that makes it easy to accidentally spread your secrets all over the Internet.
Submission deadline is Dec 2, 2014, in accordance to the rules
Winners will be announced on Dec 30, 2014.
A couple of days back, I received an interesting email from a rather curious mind.
The author of said email apparently found my contact details from one of the conference proceeding where I had submitted a paper.
Now, the author of the email posed rather curious questions, namely
…what exactly makes a quantum computer different from normal?…numerous articles point that quantum computer are superior because they can exist in two simultaneous states, but how does that exactly make a difference?…Lastly, every machine has its limits, so why is it being flaunted around as super machine?
Admittedly, given this was second email to me from a curious student so I was rather existed to answer it. Mind you, this person was also first one to continue conversations with follow up emails.
Anyways, while I did replied answers to all his questions, to the best of my abilities, it was later that I stumbled around this excellent article “What Quantum Computers Do Faster, with Caveats“. It is excellent articles that explains in short about the limitations of quantum computation. The author of this articles also uses Quantum Fourier Transform as example to explain the limitations.
One of the main idea about quantum world that I found hard to explain to him was that of superposition, something which he found surprisingly difficult to grasp; which may be attributed to his completely non-physics background.
When I had started to study about quantum information processing, I used to note down every interesting example or problem that would be capable of explaining a specific concept in a flash. Following is one of those noted example:
For example related to computer programming for understanding the superposition, one may look at a data structure called a linked list. Each data node in the list contains a pointer, to the next data node. The program traverses the list by jumping to the next data node indicated by the pointer. In a doubly-linked list, the data node contains two pointers, one for traversing to the top of the list, and another for traversing to the bottom of the list.
Another way of implementing a doubly-linked list is to use a single pointer space that contains the exclusive-or (XOR) or the two adjacent pointers. Figure below shows a link list node with pointer S that is the XOR of reference A (before) and reference B(after). To traverse the link list upward, the program XORs the current pointer (S) with the one it just left (B), and the result is the pointer of the next node (A). The same process works when traversing down the list. This superpositioning of node pointers is analogous to how the quantum states are maintained simultaneously in a quantum bit.
We can define those lists mathematically as follow:
and
Earlier on, I also had bad habit of never noting down important points without due citation or source for the information. So credit for this example to original poster or author of blog post or paper, respectively. If anyone is aware of where this appears, kindly comment.
Lastly, there are two excellent articles on the Limits of Quantum Computers by Scott Aaronson here and here.
The next Q+ hangout is all set to run on 22nd April, 14:00 UTC+1. Surprisingly, the topic this time “On the Uncertainty of the Ordering of Nonlocal Wavefunction Collapse when Relativity is Considered”, which I had earlier read through and found to be highly interesting and no less entangled, no pun.
In the EPR experiment, if Alice makes a measurement on her particle then the state of Bob’s particle collapses to the result anti-correlated to Alice’s measurement. This process is said to be happen instantaneously.
This ‘instantaneous’ gives rise to a paradox. For example, if in one reference frame Alice measures first then Bob’s state collapses. In a different inertial frame, an observer might say that Bob measured first leading to the collapse of Alice’s state. This leads to the identity paradox for who collapsed whose first!
This paper uses a type of clock device that functions on the laws of quantum-mechanics. This device in the experiment keeps the above paradox from occurring.
The bottom line being that in the experiment, Alice and Bob’s measurements cannot be made with infinite precision, rather they are constrained due to the energy-time uncertainty principle. Since energy and time are not relativistic invariant quantities, different observers in different reference frames must transform their uncertainty principles accordingly.
Concluding the paper rightfully claims the uncertainty principle in time always outruns the time difference induced by the change in reference frames. Neither Alice nor Bob will ever, with certainty, observe the two measurements swap temporal order. Furthermore, it can be said that if a time measurement performed an entangled biphoton is simultaneous in one shared reference frame then it can be considered simultaneous to all measuring observers who do not share a reference frame.
On a personal note, it was only while going through the paper I thought about the time it takes for a EPR photon to collapse when measurement taken on its pair. People have already calculated it experimentally. This hangout already sounds like exciting, fingers crossed that I can attend it uninterrupted this time, have a couple of questions for the presenter.
Further Reading
On the Uncertainty of the Ordering of Nonlocal Wavefunction Collapse when Relativity is Considered arXiv:1310.4956 [quant-ph]
The Uncertainty Relation Between Energy and Time in Non-relativistic Quantum Mechanics DOI: 10.1007/978-3-642-74626-0_8
Experimental test of relativistic quantum state collapse with moving reference frames DOI: 10.1088/0305-4470/34/35/334
This is in continuation of my previous post Apostille by MEA (Ministry of External Affairs), India [PART 1].
This information is current as of April 2nd 2014 and applicable for educational documents ONLY.
The following is true for Maharashtra State Government. State attestation can be completed in one day, in official work hours.
State Attestation:
I. After completing the previous step, collect the following documents:
II. Travel to Mumbai. It is highly recommended that you travel as early as possible (on weekdays and non-national or state holidays only).
Higher & Technical Education Department, Government of Maharashtra, Room No. 422, 4th floor, Mantralaya, Mumbai – 400032. Tel No.: 022-22043018.
III. Around 13:20, line up for entry to Home department.
Section officer, Home Department, Government of Maharashtra, 9th floor, New Administrative Building, Opp. Mantralaya, Mumbai – 400032. Tel No. 022-22022688
IV. After completing with Home Department
V. Head back to Mantralaya
That’s all with state attestation. Final apostille procedure will be detailed in next post.
TIPS :
I finally received my documents with apostille seal on them. In this post, all the procedures and necessary steps in details along with some tips that might help people in getting their documents apostilled in timely and non-frustrated way, is listed.
All the information would be split into 2 parts. Second post would soon follow.
This information is current as of April 2nd 2014 and applicable for educational documents ONLY.
Pre-attestation:
My documents originated from Maharashtra state, hence I needed state attestation prior to submitting documents for apostille. According to the stated information at MEA Official Site, one needs to get educational documents attested by Joint Secretory of Higher and Technical Education.
Unfortunately, the information listed on the MEA site is incomplete, as before the Joint Secretory can affix the documents, it must be stamped by the originating university’s registrar/controller of examination followed Notary by notarized person, ending with stamp from Home department of the state government. Thus the following steps apply:
I. Get all the originals that you wish to aspotille, stamped from the relevant university (incase of higher education documents) or relevant examination board (incase of secondary or higher secondary education documents).
II. Get all the documents notarized by a notary person. You can search for notary person near you from this page. The notary must be of Rs. 25 stamp.
Next part would be about state attestation and final apostille procedures.
kryptomusing 