django – How to handle community contributions to public database

Developing a platform that grows with the help of the community is a complex task.

I am currently experiencing difficulties in processing community contributions to my publicly available Database.

My Backend is designed using django, and people are allowed to update some data via api calls.

The structure of the Database Table is designed with three states: “draft”, “accepted” and “rejected”.

class SomeModel(models.Model):
    class Status(models.TextChoices):
        DRAFT = 'draft', _('Draft')
        ACCEPTED = 'accepted', _('Accepted')
        REJECTED = 'rejected', _('Rejected')
    top_city = models.CharField(max_length=255)
    ...
    all other attributes goes here
    ...

Let’s look at the model example above, so that after the moderator reviews the contribution of one of the users from the community, it sets the status Accepted, and this record becomes active. Let’s say someone makes changes to this particular record and these changes cannot be immediately published as they need to be reviewed before. So I can set it to a draft and apply the changes made, but in this case I will lose the previous accepted changes and also this record will be hidden from the community until it is reviewed and accepted.

I hope, I could get the point across.

How to design models so that I can save the contributions to the “temporary model” and apply them to the main model after changing their status to the adopted model.

Solution that I’m thinking about

I could created separate models for each attribute of the main model, for instance:

class PendingChangesToTopCityAttributeOfSomeModel(models.Model):
    value_to_be_reviewd = models.CharField(max_length=255)
    apply_to_model = models.ForegnKey(SomeModel)

    def reject(self):
       reject_changes
    def accept(self):
       accept changes

If I do it this way, I will end up with a huge number of models and it will be very difficult to maintain such a project.

I hope you guys have better advice how to handle this problem.

public key – Generating Bitcoin address from private key in browser console

If JavaScript is your language of choice you might be interested in bcoin – the bitcoin full node implementation and modular library written in JS. It’s designed for use in nodejs environments but can be compiled for the browser as well.

This guide in particular walks you through the process: https://bcoin.io/guides/webapp.html

Please note that web browsers are insecure environments for cryptography and especially cryptocurrency, this guide is based around public keys and testnet addresses to avoid any real risk. If you try to manage private keys in a browser’s JS environment you need to be extremely careful (use an offline computer if possible, no “chrome extensions” etc)

public key infrastructure – openssl verify error: unable to get local issuer certificate

I have a test certificate chain that I generated and it fails the openssl verify command:

openssl verify intermediate_cert.pem server_cert.pem

Included below is the intermediate certificate and the server certificate. Can anyone spot what the problem is? I also have a CA certificate which signed the intermediate certificate, but I didn’t include that because I’m not sure it’s relevant.

The intermediate cert:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            86:cd:bd:21:8c:44:d7:77
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = CA, O = service, CN = service CA
        Validity
            Not Before: Sep 18 23:13:24 2020 GMT
            Not After : Aug 25 23:13:24 2120 GMT
        Subject: C = US, ST = CA, O = service
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:be:38:0a:82:a2:c9:bd:a0:e7:75:74:b7:a8:fa:
                    4d:03:e8:68:75:87:0e:94:ff:a3:8a:de:c3:c0:8d:
                    34:38:be:36:b2:01:16:d1:79:a4:f6:ed:a4:19:3c:
                    08:15:6d:62:40:f0:8f:a3:49:01:d3:03:13:c5:2c:
                    17:ae:e6:49:a7:32:36:6a:c3:18:6c:da:64:54:6c:
                    4c:04:14:fd:e2:9f:4e:25:c9:e5:8d:e6:82:62:c1:
                    1e:d9:67:5c:9b:dd:f4:8b:19:76:c3:d3:23:1b:76:
                    ae:ee:26:b0:98:02:fe:47:a7:06:d3:a5:69:91:39:
                    53:1f:d6:fa:f9:8d:4c:41:43:3d:f6:33:e6:ca:a1:
                    eb:da:0e:77:39:cc:34:78:bd:96:72:75:0b:b1:f3:
                    85:40:e3:71:4c:b4:0f:68:a1:6b:74:07:09:74:1f:
                    a0:cb:ac:80:f3:a2:7b:08:04:9d:3e:3c:8f:a8:43:
                    2a:a5:ec:46:8a:c5:30:4d:7d:9b:8b:c6:b9:af:b2:
                    7d:13:99:a6:5d:2a:4b:55:21:ee:6e:b6:5f:9f:55:
                    2e:a1:97:2b:f0:ac:e8:f7:d2:40:6d:7c:84:bc:e9:
                    31:8b:d2:31:1f:eb:23:76:e3:74:d9:b3:c1:b3:a3:
                    ec:61:04:e2:ce:9b:00:4d:f8:2d:22:e8:eb:88:a6:
                    56:e9:12:ea:16:bb:2d:e2:70:87:cb:c3:0f:6d:8f:
                    d9:a0:f8:ac:31:a2:00:df:e6:85:75:42:f2:a4:6b:
                    f3:0c:97:ac:8a:f6:85:4a:69:e3:68:89:57:2c:d5:
                    1d:60:d1:92:ae:1d:53:7d:71:6c:db:23:ff:cf:45:
                    12:1f:97:39:88:ae:33:b6:60:78:75:7f:21:ef:3d:
                    9e:be:fc:bc:e7:ef:d2:20:8c:80:21:6c:ca:4a:45:
                    67:ef:2f:0c:2d:b6:9b:aa:46:ae:5e:7c:55:d6:39:
                    f5:de:a3:1e:da:4d:b5:06:16:9f:50:79:c3:10:71:
                    d2:e8:0f:1d:dd:2e:47:20:6f:93:cc:eb:21:ff:40:
                    eb:44:2c:43:9e:85:de:29:89:0b:a7:51:fb:84:7c:
                    33:cb:7c:e1:69:ba:b0:34:00:56:f8:f2:62:8c:bd:
                    bb:87:b8:ac:b5:d3:e4:83:05:1c:68:c8:ed:57:5a:
                    84:0d:01:98:80:73:04:b7:ce:6f:a6:54:5f:69:da:
                    d1:c9:06:bd:5b:bc:0c:2a:e6:f6:52:4f:d4:d6:29:
                    1e:e4:37:5b:61:f0:b3:5f:ab:30:3d:14:44:9a:99:
                    cb:f0:f6:6e:db:4f:c5:58:13:ff:92:aa:09:2a:66:
                    06:3b:ec:bf:6b:a7:4d:fc:55:6d:92:27:41:01:6d:
                    b7:bd:25
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                12:DF:81:75:71:CA:92:D3:CE:1B:2C:2B:77:3B:9E:33:77:F3:F7:6F
            X509v3 Authority Key Identifier: 
                keyid:0E:03:13:DC:2F:CC:CC:5C:04:2F:57:82:5D:76:8D:62:FE:07:CD:46

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         4f:95:dc:b0:8f:0c:9e:b3:ef:2e:86:62:ba:7f:f5:bd:28:28:
         ef:f0:dc:c0:f2:ce:dc:11:ea:d9:92:85:de:e6:31:8a:1d:98:
         e6:ba:e5:07:f1:96:81:b6:15:f9:60:65:14:81:7a:46:da:9c:
         d6:8d:ac:2c:85:a8:5a:3c:e0:c5:a2:c3:3a:61:5e:1e:e9:c5:
         61:39:6a:26:9e:08:f2:81:ce:a5:48:2b:f9:b0:98:c9:79:ba:
         20:35:f8:6a:a3:8e:74:16:07:c6:1c:68:3a:b0:0a:38:d1:92:
         d7:e4:4a:45:a1:b6:7c:2d:b7:d9:73:e5:0c:c1:4e:38:fd:c7:
         ff:f9:b0:c3:af:4c:7c:57:ca:d5:f9:1c:58:e1:74:28:a6:56:
         47:8d:ea:a1:83:2a:df:27:1a:10:25:3b:62:a6:63:53:fd:30:
         b7:72:29:85:0d:ca:18:ce:6b:94:63:c2:d8:d3:c8:bf:70:9b:
         fe:b9:69:8e:c4:ee:69:d5:1e:f0:a2:36:8b:48:49:33:e1:8e:
         78:39:1a:55:2d:ad:9c:2e:b7:86:9d:32:89:6b:f1:8b:cb:b6:
         04:5c:bd:5d:91:c0:fa:c6:5c:84:03:0e:2e:f5:2a:48:9e:c0:
         82:47:d9:2b:1d:9f:49:62:11:83:12:7a:56:74:65:1c:28:96:
         c2:52:e8:c7:ac:5f:d3:64:04:bd:3f:25:69:38:a0:87:d5:ca:
         65:39:fa:17:c1:59:ac:ea:42:c4:94:ce:01:e7:b1:11:c8:0f:
         99:13:61:7b:ea:7d:b0:45:8f:c5:95:ad:54:f7:d3:62:69:61:
         b3:68:18:94:58:77:1b:14:62:79:59:aa:ef:9f:62:6d:1f:fd:
         4f:54:1a:15:16:4f:68:c9:c7:61:63:88:09:73:db:e7:a0:eb:
         92:dc:e3:e0:96:e5:28:ca:99:3d:6e:a9:fc:1b:2e:9f:7d:24:
         07:af:d4:a7:42:3c:1f:b9:72:2f:36:7a:40:7e:65:2b:06:70:
         b4:0f:71:f8:13:07:a7:57:82:39:e8:f5:87:a0:5d:a8:69:c5:
         29:67:bd:55:d1:6d:ff:b6:2a:f5:cd:d8:45:37:6b:c7:ed:1a:
         55:e4:26:0b:ba:e1:da:ff:84:9f:0d:ed:1c:8c:91:81:dc:8c:
         d0:5c:f2:d3:ef:40:03:5f:52:a6:7f:56:cc:4d:59:fa:fe:10:
         d9:42:db:a0:e9:45:d4:12:5e:cc:64:81:15:ca:c7:9e:cc:dd:
         04:f7:1a:37:d0:c8:92:80:41:ba:07:d9:ce:7b:49:04:01:c9:
         f1:e3:d3:6b:15:c1:b9:1b:ea:fb:e5:9b:cc:fa:a8:71:06:f0:
         93:a7:a0:75:ad:0f:3e:b1

The server cert:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 30584 (0x7778)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = CA, O = service
        Validity
            Not Before: Sep  5 05:39:25 2017 GMT
            Not After : Aug 12 05:39:25 2117 GMT
        Subject: C = US, ST = CA, O = service, CN = service Test Cert
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b1:d3:62:20:76:1e:b6:19:b5:d7:61:79:6a:f0:
                    3f:72:6d:85:df:8f:8b:bf:af:df:9d:5e:5e:bc:d1:
                    aa:69:5f:5e:bf:7e:41:d0:1b:e2:fb:4b:cc:4d:ac:
                    76:45:48:f8:28:a0:0c:5d:cc:e7:cf:e1:33:48:a8:
                    da:37:93:de:ce:c6:56:7b:42:6c:33:df:6c:c0:06:
                    05:36:8d:dc:90:89:72:4d:83:2e:d6:42:9f:5d:8f:
                    bb:62:0d:93:bb:55:5a:01:ba:3b:fc:ac:c6:0c:42:
                    6d:10:3c:90:4c:37:ff:1f:de:cc:d9:33:2a:aa:2f:
                    b7:c9:2d:a3:2b:87:65:8e:34:8d:dd:2a:5c:82:ca:
                    1e:db:da:d3:69:62:38:4c:20:59:86:ab:ca:be:ca:
                    4c:49:7f:b6:57:9a:37:f3:a0:25:2d:ac:25:22:ff:
                    d8:19:e8:66:bf:cc:d3:04:7a:84:10:ea:fd:d8:1f:
                    80:23:e6:e6:1a:23:53:f1:a5:8d:98:04:74:a2:0a:
                    54:a2:6b:6d:11:1c:2f:70:ff:dd:a2:76:3a:ea:d6:
                    2f:12:5a:a0:39:bb:13:b1:13:34:f6:96:1e:b5:e8:
                    f7:65:83:bb:02:ca:24:4f:79:bd:2d:74:e3:4b:b8:
                    48:3a:65:00:b5:bc:24:48:3a:57:ae:7e:91:a4:71:
                    b7:29
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            X509v3 Subject Key Identifier: 
                06:2D:AD:32:62:BA:AD:46:C1:D7:34:7B:F8:FE:74:A4:AB:C1:AC:54
            X509v3 Authority Key Identifier: 
                keyid:12:DF:81:75:71:CA:92:D3:CE:1B:2C:2B:77:3B:9E:33:77:F3:F7:6F
                DirName:/C=US/ST=CA/O=service
                serial:86:CD:BD:21:8C:44:D7:77

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            Authority Information Access: 
                OCSP - URI:http://ocsp.ocsptest.com

    Signature Algorithm: sha256WithRSAEncryption
         93:de:af:c1:bd:37:5c:64:55:b0:08:27:69:44:bf:c4:59:98:
         b7:b0:bc:99:7d:8e:c7:5b:26:a2:45:6b:f1:ed:d1:c5:80:50:
         c3:c8:94:50:96:be:8d:c8:58:38:a9:f0:a5:ba:5a:25:74:15:
         ce:9a:71:02:6d:97:f3:7e:dd:9b:b1:ef:bd:55:a1:68:60:fb:
         bb:b6:5b:94:22:74:d9:f9:ea:d1:1c:bb:08:63:62:88:0d:e8:
         f8:17:3b:c9:91:cb:6d:b7:fb:55:b8:2b:a3:89:34:ba:81:28:
         04:75:d4:0a:4a:11:68:f1:ce:4b:3a:c1:de:a8:3a:af:67:fd:
         7c:f9:6d:6f:ad:7b:c0:1a:7e:e2:05:66:29:ee:11:fe:2b:76:
         ac:e0:ec:27:93:9e:bf:59:d8:79:cf:6a:7f:f3:b7:37:59:a6:
         95:05:c2:05:59:23:4e:73:10:6e:9b:ff:d2:e0:21:c9:2f:5c:
         ac:6f:77:53:45:24:40:4f:3c:bf:82:f7:8d:ee:18:1a:9b:fb:
         c8:99:e4:38:21:67:ed:39:f0:c6:b9:16:29:1e:05:51:92:70:
         ec:b3:39:f8:32:93:93:ac:10:66:a6:29:c5:f2:31:9c:e4:bf:
         31:13:fe:3f:e0:b4:57:67:4a:13:9d:62:5e:a3:ee:08:1e:68:
         70:e7:42:12:11:a0:e2:1a:a5:cc:bb:50:c9:1e:4c:97:8b:96:
         0c:c3:fd:6c:df:c2:5d:3c:3e:6e:87:df:be:53:b7:e0:f9:ee:
         46:d3:50:d8:6c:64:1c:e5:6a:0a:fb:b4:7a:20:3b:e0:36:b5:
         8c:ea:18:b5:e0:77:58:75:38:05:98:31:8b:dd:7c:99:3d:b4:
         91:27:09:bb:0b:cf:c2:1a:1d:6f:3d:93:15:1a:80:63:a6:b3:
         24:00:5b:f0:c5:ef:87:84:9c:5e:df:e4:a4:df:af:31:64:85:
         b3:75:1e:05:c2:30:04:b6:36:ec:2d:08:c4:ea:43:6e:67:cb:
         a6:20:f1:42:f6:35:02:c5:68:1d:dc:2b:70:c8:8e:6d:5c:56:
         d5:78:28:de:0e:a7:fa:03:9c:67:7a:0e:56:fe:e7:4b:9d:3f:
         37:50:ec:2c:c8:fa:15:c2:00:3e:33:4e:24:b9:de:91:4c:9f:
         91:ed:bb:01:c9:06:32:05:a2:00:78:12:21:69:76:0b:86:de:
         cd:64:85:34:28:ad:e9:22:08:11:9f:95:b4:42:f7:29:0c:ab:
         7c:bf:32:99:5a:e8:ef:10:a7:fa:98:89:fe:44:c2:48:b8:37:
         ff:a5:cd:a4:97:05:88:7a:ab:6e:db:c3:b2:de:38:bd:7c:a3:
         2c:ac:3d:07:42:0a:15:c7

address – Public key management

A modern Bitcoin wallet program can generate many private-keys, each private-key has a public-key. For the most common transaction types, a Bitcoin-address is derived from the public-key.

As you say it is normal to generate a new address (i.e. a new set of keys) for each transaction. This is because all the transaction data is public knowledge – it is in the replicated journal of transactions we call the blockchain. Anyone can see all transactions for a specific address, so if ten people each pay you 1 BTC to the same address, they can all see that you have received 10 BTC in total at that address. This is a privacy concern. If the addresses are all different, they can’t tell which belong to the same person.

In the Bitcoin network there are no accounts, no virtual accounts and no balances.

A wallet can read through the whole transaction journal and add up all the unspent amounts in transactions where the receiving address is one for which the wallet knows it has the corresponding private-key. That way it can present a total amount to the user. People refer to this total as a balance but that’s misleading. The Bitcoin network does not keep a record of people’s balances. The Bitcoin network does not know how much money anyone has in total. The US Mint does not know how many US one-cent coins I have sitting in a plastic bag on my shelf, it doesn’t keep track of my balance or have an account in my name.

The terminology for Bitcoin is a bit muddled. Bitcoin was designed as digital cash. Accounts and balances are associated with banks, not with piles of dollar bills under your mattress or in your leather wallet. If you were talking about cash in the form of paper money and metal coins you wouldn’t think about accounts and balances. You’d just want to know the total amount of money you have in paper banknotes and metal coins.

Modern wallets are what is called Hierarchical Deterministic (HD) wallets. From the initial private key (or seed phrase) it is possible to generate all the subsidiary keys and addresses in a predictable and repeatable way. You don’t need to make a backup of each generated key and generated address.

public key infrastructure – PKI Usage in Trusted Boot

I am trying to understand how PKI is used to boot an ARM board.

The following image relates to BL1:

enter image description here

The booting steps state:

enter image description here

Also from:

enter image description here

The certificate used in step 1 appears to be a content certificate. In the diagram it suggests in contains the public key used to sign a hash, and the signed hash for BL2.
Referring to X-509 certificate:

enter image description here

My question is that from the description above, is ARM not using the subject public key information in X509, and is instead adding the public key used to verify the hash in the extension field, and the signed hash in the digital signature field ?

The diagram also indicates that the trusted key certificate contains 3 keys (ROTPK, TWpub, NWpub). Does that mean that put all 3 keys in extension field, then added the signed hash of perhaps TWpub + NWpub in the digital signature and again didn’t use the subject public key information field (with certificate later verified with the ROTPK in the extension field) ?

c# – Design issues/questions regarding internal interfaces in assembly and abstract base class in a public constructor

For information, I have been redirected from Stack OverFlow: https://stackoverflow.com/questions/63888557/design-issues-questions-regarding-internal-interfaces-in-assembly-and-abstract-b?noredirect=1#comment112978234_63888557

I’m currently facing a design issue while coding an assembly. I think it will be easier to understand by using the following example.
This assembly defines several lights which all have a state that can be known from outside of the assembly:

public interface ILight
{
    bool State { get; }
}

The capacity to turn a light off or on is only allowed internally so that I define an internal interface as such:

internal interface IInternalLight : ILight
{
    void SwitchOn();
    void SwitchOff();
}

Finally, from an external perspective, the assembly consumer can instantiate and use the LightManager class to act on lights:

public class LightManager
{
    private List<IInternalLight> lights;

    public List<ILight> Lights
    {
        get { return lights.ConvertAll(x => (ILight) x); ; }
    }

    public LightManager(List<IInternalLight> lights)
    {
        this.lights = lights;
    }

    public void SwitchOn()
    {
        foreach (IInternalLight light in lights)
        {
            light.SwitchOn();
        }
    }

    public void SwitchOff()
    {
        foreach (IInternalLight light in lights)
        {
            light.SwitchOff();
        }
    }
}

Of course, in the above example, I obtain a compilation error because IInternalLight is internal and cannot be exposed in a public constructor.

My way to solve this consists in defining an abstract class called LightBase which implements the internal interface:

public abstract class LightBase : IInternalLight
{
    protected bool _state = false;

    public bool State
    {
        get { return _state; }
    }

    internal LightBase() { }

    void IInternalLight.SwitchOff()
    {
        _state = false;
    }

    void IInternalLight.SwitchOn()
    {
        _state = true;
    }
}

so that a licit constructor for LightManager can be:

public LightManager(List<LightBase> lights)
{
    this.lights = lights;
}

While it’s working, I’m a bit puzzled by the following points:

  • in first place, I thought my design would simply consists of a single interface containing the internal part and several concrete classes (SimpleLight, ComplexeLight, VeryComplexeLight, …). C# forbids that so that a second interface purely internal is required and then I end up with an abstract class as well. It looks rather “complex” for such a small case.
  • I don’t know if exposing an abstract base class in a public constructor is a good practice. Actually I expected to only expose interfaces for testing purposes (typically for injection dependency). I don’t think exposing a public class called Light for example suits better.

Thank you.

How critical is encryption-at-rest for public cloud hosted systems

I wok as a solutions architect for web based systems on AWS and as part of this role often respond to Information Security questionnaires. Nearly all questionnaires request information about data encryption at-rest and in-transit. However only a much smaller percentage ask about other security aspects, such as password policies or common web application security issues, as published by OWASP.

I wonder how common/ likely accessing of clients data is within a public cloud provider such as AWS, Azure and GCP. It seems a very high barrier to pass for an external party, even data centers of small local web hosting companies seem to have very good physical access security. And informal conversations with bank employees tell me that accessing someone’s bank account without reason leads to instant dismissal, so surely public cloud providers would have similar controls in place?

This is not to challenge the value of encryption at rest, it is very cheap to access, so there is no reason not to enable it, but where does it sit in terms of priorities?

public key infrastructure – Trying to understand the encryption used at various steps of Tor

So I read up on “Diffie-Hellman” key exchange which to my knowledge is a way for two parties to create a “shared secret” but I don’t really know if this is a public key or a private key or something else entirely.

When I look up how Tor works, many videos use the analogy of the locked box. We establish an entry node, relay node, exit node (call them A, B, C). I send a locked box to A who unlocks it and inside is another locked box with a message included, “send this to B.” A sends this box to B, who unlocks it and sees another locked box with a note, “send this to C.” B sends the box to C, who unlocks it and sees a message, “Fetch the contents of somewebsite.com” (the final request).

I don’t know if this analogy makes sense or if it’s even accurate.

Is this key exchange something that is done with the client and each of the three nodes, and that is how I am able to encrypt the message several times? Or is there some other algorithm used instead? I see that Tor uses RSA but I’m still unclear on how it all works together.

Trying to understand what is going on. It would help to see a minimal example using the actual encryption techniques.

public transport – Best Route from Zurich Airport to Rhine Falls

I am confused between so many different options of SBB tickets and travel passes. I will arrive Zurich Airport on 18th September’s morning. From there, I want to go to Rhine Falls and return to Zurich on the same day. In Zurich, I want to reach the Technopark to be exact.

I am looking for the best and cheapest route to do a round trip to and from Rhine Falls and then reach Technopark (inter-city travel). On Sunday, I will have to go back to the airport form there.

Which tickets/pass should I buy?

Any recommendations?

public key – How to generate Hash160 from a private key with the Bitcoin module

I want to fix the script code. The script generates from a random private key Bitcoin Address by function (pubtoaddr) and works
on the Bitcoin module:

https://github.com/primal100/pybitcointools/blob/master/cryptos/main.py

from bitcoin import *
import os

    priv = random_key ()
    pub = privtopub (priv)
    addr = pubtoaddr (pub)

....
....

But I need to get from a Random Private Key in Hash160

For some reason I could not find such a function in main.py

I searched and found an article

>>> import pybitcointools
>>> privkey = pybitcointools.random_key ()
>>> privkey
'34030ce14e32ac982419b3683af3b59d64a29cc93798cf479d610af49d425d13'
>>> pubkey = pybitcointools.privtopub (privkey)
>>> pubkey
'04ce0ed35340803b0c21f2f7f5d5ab9d687e5fa95a79471c9b5c9d97a0bb170eac1045230cc51d13b85a5f64feb80f8fc19358a396797926e3f89d49066b1abc07'
>>> h160 = pybitcointools.hash160 (pubkey.decode ('hex'))
>>> h160
'1558c7cd9825447a31990ff964f347bb2dbfe9be'
>>> addr = pybitcointools.hex_to_b58check (h160)
>>> addr
'12wsYc4B9c9JeREqstLZXNWa3n4i42M5jg'

Unfortunately I could not get from

 priv = random_key ()  --- > Hash160

How to do it?