Use AES in CTR mode with pycrypto The doc of pycrypto gives an example of using AES in CTR mode: 

&gt;&gt;&gt; from Crypto.Cipher import AES
&gt;&gt;&gt; from Crypto.Util import Counter
&gt;&gt;&gt;
&gt;&gt;&gt; pt = b''*1000000
&gt;&gt;&gt; ctr = Counter.new(128)
&gt;&gt;&gt; cipher = AES.new(b''*16, AES.MODE_CTR, counter=ctr)
&gt;&gt;&gt; ct = cipher.encrypt(pt)


I think this isn't safe for encryption of multiple messages with the same key because the counter value defaults to 1. Would it be safe if I do:

iv = os.urandom(16)
ctr = Counter.new(128, initial_value=int.from_bytes(iv, 'big'))


Some articles recommend a timestamp-based nonce (e.g. 64-bit timestamp + 64-bit random value). I was wondering if it's OK to simply draw a 128-bit random value with urandom, and if this implementation is flawless.
Probably the best thing to do is to decide the maximum message size in bytes, then divide that size by 16 (the block size), call that $m_c$. The number of bytes required to encode $m_c$ is called $l_c$.

Create an IV of 16 bytes and randomize the first (leftmost) bytes, leaving at least $l_c$ bytes at zero. You then have a non-repeating counter of size $l_r$ bytes where $l_r = n - l_c$. That means that you can encrypt about $2^{l_r * 8 - 64}$ messages with the same key while still having a rather small chance of ever repeating the random nonce $r$ and thus the counter.

Time stamps are dangerous, an attacker can try and control the time, clocks can get out of sync, and there may be precision related issues. Time stamps are therefore commonly not used to create nonces - for encryption modes anyway. You don't want to use /dev/random either. Generally /dev/urandom is secure and at least it doesn't block.