Verify cert and private key of pair created using EC algorithm

 

Retrieve the public key from cert and do a md5

openssl x509 -in server.crt -pubkey -noout | openssl md5

 

Retrieve the public key from private key and do a md5

openssl pkey -pubout -in server.key | openssl md5

If the outputs from two commands match, then the certificate must be created from the private key.

Hyperledger Fabric event listener

 Function to listen to chaincode event

func listenEvents() {

cnfg := config.FromFile("./connection.json")

fmt.Println(reflect.TypeOf(cnfg))

sdk, err := fabsdk.New(cnfg)

if err != nil {

fmt.Printf("Failed to create new SDK: %s", err)

}

defer sdk.Close()

clientChannelContext := sdk.ChannelContext(channelID, fabsdk.WithUser(orgAdmin), fabsdk.WithOrg(orgName))

eventClient, err := event.New(clientChannelContext, event.WithBlockEvents(),

event.WithSeekType(seek.Oldest))

if err != nil {

fmt.Printf("Not be able to create new events client: %s", err)

}

reg, notifier, err := eventClient.RegisterChaincodeEvent("offering", "OFFERING SUBMITTED")

defer eventClient.Unregister(reg)

donechannel := make(chan string)

go func() {

// Just a function to demostrate that we can send signal to end the listening loop

time.Sleep(1 * time.Minute)

donechannel <- "QUIT NOW"

}()

defer close(donechannel)

end:

for {

select {

case ccEvent := <-notifier:

fmt.Printf("Received cc event: %#v", ccEvent)

fmt.Printf("The payload is %v", ccEvent.Payload)

fmt.Printf("TxID is %s", ccEvent.TxID)

case msg := <-donechannel:

fmt.Printf(msg)

break end

}

}

fmt.Println("Process finished")

}

Query Fabric transaction

 

func useClientQuery() {

cnfg := config.FromFile("./connection.json")

fmt.Println(reflect.TypeOf(cnfg))

sdk, err := fabsdk.New(cnfg)

if err != nil {

fmt.Printf("Failed to create new SDK: %s", err)

}

defer sdk.Close()

clientChannelContext := sdk.ChannelContext(channelID, fabsdk.WithUser(orgAdmin), fabsdk.WithOrg(orgName))

client, err := ledger.New(clientChannelContext)

if err != nil {

fmt.Printf("Can not get ledger client")

} else {

fmt.Printf("The client is %v", client)

}

tx, err := client.QueryTransaction("e969096e24e768bff2df17d640404b6b72093fa008509acaa31cc8adb6c72260")

fmt.Printf("validation code %d", tx.GetValidationCode())

fmt.Printf("The tx is %v", tx)

//client.QueryBlock()

//client.QueryBlockByTxID("e969096e24e768bff2df17d640404b6b72093fa008509acaa31cc8adb6c72260")

}

Zero knowledger proof non-interactive

How to make zero-knowledge proofs non-interactive?

 

With earlier zero-knowledge verification systems there was one big problem. For it to work, the prover and the verifier had to be online at the same time. In other words, the process was “interactive”. This made the entire system inefficient and almost impossible to scale up. The verifiers couldn’t possibly be online at the same time as provers all the time? There needed to be a system to make this more efficient.

In 1986, Fiat and Shamir invented the Fiat-Shamir heuristic and successfully changed the interactive zero-knowledge proof to non-interactive zero knowledge proof. This helped the entire protocol work without any interaction. The procedure behind it is very simple.

So, to give you an example, this is how zero knowledge proofs used to work before Fiat and Shamir. Let’s prove this using simple discrete logarithms.

 

• Anna wants to prove to Carl that she knows a value x such that y = g^x to a base g.

 

• Anna picks a random value v from a set of values Z, and computes t = g^v and sends t to Carl.

 

• Carl picks a random value c from the set Z and sends it to Anna.

 

• Anna computes r = v-c*x and returns r to Carl.

 

• Carl checks if t= g^r * y^c  holds or not ( since r= v-c*x, y= g^x and by simple substitution, g^(v-c*x)* g ^ c*x = g^v = t).

 

• Carl doesn’t know the value of x, by merely checking if t = g^r * y^c he can verify that Anna does indeed know the value of x.

 

Now while the above interaction is zero-knowledge, the problem with this is that Anna and Carl need to be online and exchanging values for it to work.

How can Anna prove to Carl that she has knowledge of something without Carl being online? She can do so by using a simple cryptographic hash function, as Fiat and Shamir theorized.

 

Let’s look how the example above would work in a non-interactive way:

 

• Anna wants to prove to Carl that she knows a value x such that y = g^x to a base g.

 

• Anna picks a random value v from a set of values Z, and computes t = g^v.

 

• Anna computes c = H(g,y,t) where H() is a hash function.

 

• Anna computes r = v – c*x.

 

• Carl or anyone can then check if t = g^r * y^c.

 

So, as you can see, zero knowledge proofs were made non interactive. And this was what laid the foundations for Zk-Snarks.

 

The above content is taken from this link https://blockgeeks.com/guides/zcash/

Create self signed certificates

 ################## Create root ca certificate
# Create a private key
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -pkeyopt ec_param_enc:named_curve -out ca.key

# Extract the public key
openssl ec -in ca.key -pubout -out ca_public.key

# Create signing certificate in one step
# Create root ca certificate
openssl req -new -days 3650 -nodes -x509 -extensions v3_req -extensions v3_ca \
  -subj "/C=US/ST=North Carolina/L=Raleigh/O=org0.example.com/CN=ca1.org0.example.com" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment,keyCertSign,cRLSign" \
  -addext "extendedKeyUsage=serverAuth,clientAuth" \
  -addext "subjectAltName=IP.1:192.168.56.32" -key ca.key  \
  -out ca.crt

# Inspect the certificate
openssl x509 -noout -text -in ca.crt

################ Create User certificate
# Create private key for admin
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -pkeyopt ec_param_enc:named_curve -out admin.key

# Extract public key for admin
openssl ec -in admin.key -pubout -out admin_public.key

# Create admin CSR
openssl req -new -key admin.key -extensions v3_req \
  -subj "/C=US/ST=North Carolina/L=Raleigh/OU=admin/OU=client/CN=Admin@org0.example.com" \
  -out admin.csr

# Verify CSR
openssl req -verify -text -noout -in admin.csr

# The content of v3.ext file
# keyUsage = critical,digitalSignature
# basicConstraints = critical,CA:FALSE
# authorityKeyIdentifier = keyid,issuer

# key usage can be other values as well
# keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

# Now sign the CSR with ca key and cert
openssl x509 -req -days 3560 -extfile v3.ext -in admin.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -sha256 -out admin.crt

# Verify certificate
openssl x509 -noout -text -in admin.crt

################ Create peer and orderer certificate
# Create private key for peer1
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -pkeyopt ec_param_enc:named_curve -out peer1.key

# Extract public key for peer1
openssl ec -in peer1.key -pubout -out peer1_public.key

# Create peer1 CSR
openssl req -new -key peer1.key -extensions v3_req \
  -subj "/C=US/ST=North Carolina/L=Raleigh/OU=peer/CN=peer1.org0.example.com" \
  -out peer1.csr

# Verify CSR
openssl req -verify -text -noout -in peer1.csr

# The content of v3.ext file
# keyUsage = critical,digitalSignature
# basicConstraints = critical,CA:FALSE
# authorityKeyIdentifier = keyid,issuer

# key usage can be other values as well
# keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

# Now sign the CSR with ca key and cert
openssl x509 -req -days 3560 -extfile v3.ext -in peer1.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -sha256 -out peer1.crt

# Verify certificate
openssl x509 -noout -text -in peer1.crt

Windows 10 docker desktop volumes

 Windows 10 docker desktop made a lot of changes between wsl and wsl2 especially how the mount works. This change created a lot of issues. Here is the main difference:

WSL:

mount point starts at this:

on drive C: /host_mnt/c

on drive D: /host_mnt/d

WSL2:

mount point starts like this

on drive C: /run/desktop/mnt/host/c

on drive D: /run/desktop/mnt/host/d

certificates key usage and extended key usage

Key usage and extended key usage

Key usage extensions define the purpose of the public key contained in a certificate. You can use them to restrict the public key to as few or as many operations as needed. For example, if you have a key used only for signing or verifying a signature, enable the digital signature and/or non-repudiation extensions. Alternatively, if a key is used only for key management, enable key encipherment.

Key usage

The following table describes the key usage extensions available for certificates created using the CA process.

Note: The digital signature and data encipherment key usage extensions are enabled by default for all Internet certificates.

Table 1. Key usage extensions

Key usage extension	Description
Digital signature	Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.
Non-repudiation	Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing).
Key encipherment	Use when a certificate will be used with a protocol that encrypts keys. An example is S/MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment.
Data encipherment	Use when the public key is used for encrypting user data, other than cryptographic keys.
Key agreement	Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers.
Certificate signing	Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates.
CRL signing	Use when the subject public key is to verify a signature on revocation information, such as a CRL.
Encipher only	Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement.
Decipher only	Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement.

Extended key usage

Extended key usage further refines key usage extensions. An extended key is either critical or non-critical. If the extension is critical, the certificate must be used only for the indicated purpose or purposes. If the certificate is used for another purpose, it is in violation of the CA's policy.

If the extension is non-critical, it indicates the intended purpose or purposes of the key and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. The extension is then only an informational field and does not imply that the CA restricts use of the key to the purpose indicated. Nevertheless, applications that use certificates may require that a particular purpose be indicated in order for the certificate to be acceptable.

If a certificate contains both a critical key usage field and a critical extended key usage field, both fields must be processed independently, and the certificate be used only for a purpose consistent with both fields. If there is no purpose consistent with both fields, the certificate must not be used for any purpose.

Table 2. Extended key usage

Extended key	Enable for these key usage extensions
TLS Web server authentication	Digital signature, key encipherment or key agreement
TLS Web client authentication	Digital signature and/or key agreement
Sign (downloadable) executable code	Digital signature
Email protection	Digital signature, non-repudiation, and/or key encipherment or key agreement
IPSEC End System (host or router)	Digital signature and/or key encipherment or key agreement
IPSEC Tunnel	Digital signature and/or key encipherment or key agreement
IPSEC User	Digital signature and/or key encipherment or key agreement
Timestamping	Digital signature, non-repudiation.