2022-05-31T18:32:51Z

Fireduck:

2022-04-21T04:04:28Z

Fireduck:

Security Review 1 - CVE-2022-21449: Psychic Signatures in Java

## Overview

In this CVE some versions of Java do not do proper validation of ECDSA signatures and the signatures can be trivially faked.

This of course seems alarming since Snowblossom makes extensive use of ECDSA signatures, especially for seed based wallets.

However, in review of the issue it was found that while the flaw does absolutely exist in some versions of Java, no version of Snowblossom
uses the Java provided security provider for ECDSA signatures.

In the relevant section of Snowblossom code, we are always explicitly using the Bouncy Castle (BC) cryptographic provider.

Signature sig_engine = Signature.getInstance(algo, Globals.getCryptoProviderName());

## References

https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/

## Test Procedure

On a system with the problematic java versions the test code was run to reproduce the issue.
<code>
<pre>
Testing blank signature with bouncycastle:
Should report false meaning bad signature did not validate
false

Testing blank signature java provider:
Should report false meaning bad signature did not validate
true
</pre></code>

As expected, the bouncy castle does not have the problem but the java provider does.

## Test Code
<code><pre>
import java.security.*;

import java.math.BigInteger;
import org.bouncycastle.asn1.*;

public class Prob
{
public static byte[] getBlankSig()
throws Exception
{
BigInteger r = BigInteger.ZERO;

BigInteger s = BigInteger.ZERO;

ASN1EncodableVector v = new ASN1EncodableVector();
v.add(new ASN1Integer(r)); v.add(new ASN1Integer(s));

return new DERSequence(v) .getEncoded();

public static void main(String args[]) throws Exception
{
Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());

KeyPair keys = KeyPairGenerator.getInstance("EC").generateKeyPair();
Signature sig_engine = Signature.getInstance("SHA256WithECDSA");
sig_engine.initSign(keys.getPrivate());
sig_engine.update("proper data".getBytes());

System.out.println("Testing blank signature with bouncycastle:");
System.out.println("Should report false meaning bad signature did not validate");
{
Signature sig = Signature.getInstance("SHA256WithECDSA","BC");
sig.initVerify(keys.getPublic());
sig.update("Hello, World".getBytes());
System.out.println(sig.verify(getBlankSig()));
}
System.out.println();
System.out.println("Testing blank signature java provider:");
System.out.println("Should report false meaning bad signature did not validate");
{
Signature sig = Signature.getInstance("SHA256WithECDSA","SunEC");
sig.initVerify(keys.getPublic());
sig.update("Hello, World".getBytes());
System.out.println(sig.verify(getBlankSig()));
}

}
}
</pre></code>

Security/SR-1

2022-04-21T04:01:45Z

Fireduck: Created page with "Security Review 1 - CVE-2022-21449: Psychic Signatures in Java ## Overview In this CVE some versions of Java do not do proper validation of ECDSA signatures and the signatur..."

Security Advisory

2022-04-21T03:55:59Z

Fireduck:

ConfigOption/tls key path

2022-02-28T23:19:41Z

Fireduck:

ConfigOption/tls key path

2022-02-28T23:19:20Z

Fireduck: Created page with "==tls_key_path== Controls which key is used for signing the certificates used for TLS server side communication. When TLS service ports are enabled, this must be set. If th..."

==tls_key_path==

Controls which key is used for signing the certificates used for TLS server side communication.

When TLS service ports are enabled, this must be set.

If the path is empty, it will be created on startup. To get the node: address for the key, either look at the logs for a line like:

<code>
INFO: My TLS address: node:h68q5s0xxs3pc5xhcyfa076j2a6942y6edlxn429
</code>

Or see address.txt in the tls_key_path directory.

General URI form is: schema://host[:port][/?key=node:...]

If using grpc+tls, the optional key parameter specifies which TLS key the node is expected to use.

For best security and privacy it is best to use grpc+tls and specify the key.

===Default===
None
===Examples===
<code>

node_uri=grpc://snow-tx1.snowblossom.org

node_uri=grpc://snow-tx1.snowblossom.org:2338

node_uri=grpc+tls://snow-tx1.snowblossom.org

node_uri=grpc+tls://snow-tx1.snowblossom.org?key=node:fgmfupck7seaq8t2gl6plzs5vh7nyl6656wscgq3

node_uri=grpc+tls://snow-tx1.snowblossom.org,grpc+tls://snow-de1.snowblossom.org

</code>

[[Category:ConfigOptions]]
[[Category:ConfigOptionsNode]]
[[Category:ConfigOptionsMrPlow]]

Trustnet

2022-02-25T22:39:05Z

Fireduck:

==Trustnet==

The concept of trustnet is that with sharding, we will eventually reach a network where no one node has all of the chain data. However, in order to mine a block on a shard, it may need to import blocks from other shards. Including incorrect blocks will result in the new mined block being invalid so a miner must completely trust the source of data about validity of other shards.

The solution is the trustnet. The most basic use is a mining pool operator will run their nodes with the same trustnet keys so that they trust each other for other shard validation and can safely import blocks
from those chains.

For clients, a client may be configured to prefer to use nodes of a specified trustnet in order use trusted nodes that are giving correct information and not acting as address honeypots.

Trustnet

2022-02-25T21:00:06Z

Fireduck: Created page with "==Trustnet== The concept of trustnet is that with sharding, we will eventually reach network where no one node has all of the chain data. However, in order to mine a block o..."

==Trustnet==

The concept of trustnet is that with sharding, we will eventually reach network where no one node has all of the chain data. However, in order to mine a block on a shard, it may need to import blocks from other shards. Including incorrect blocks will result in the new mined block being invalid so a miner must completely trust the source of data about validity of other shard.

The solution is the trustnet. The most basic use is a mining pool operator will run their nodes with the same trustnet keys so that they trust each other for other shard validation and can safely import blocks
from those chains.

For clients, a client may be configured to prefer to use nodes of a specified trustnet in order use trusted nodes that are giving correct information and not acting as address honeypots.

ConfigOption/trustnet key path

2022-02-25T20:53:56Z

Fireduck: Created page with "==trustnet_key_path== If set, this marks the node as a member of the trustnet group indicated by the key in the path. If the path is empty or does not exist, a new key w..."

==trustnet_key_path==

If set, this marks the node as a member of the [[trustnet]] group indicated by the key in the path.

If the path is empty or does not exist, a new key will be created.

===Default===
No default

===Examples===
<code>
trustnet_key_path=trustnet_key
</code>

[[Category:ConfigOptions]]
[[Category:ConfigOptionsNode]]

Proposals

2022-02-14T19:40:49Z

Fireduck:

SIP5-Sharding

2022-02-07T05:51:44Z

Fireduck:

Proposals

2022-02-07T05:38:29Z

Fireduck:

SIP5-Sharding

2022-02-07T05:37:58Z

Fireduck:

== Overview ==

This proposal is to bring in the changes in the [https://github.com/snowblossomcoin/snowblossom/tree/shardo shardo] branch. This change includes the following:
* Adding a sharded L1 scaling solution
* Revamp of P2P block synchronization
* Updating version number to 2.0

The documentation for these changes are in [https://docs.google.com/document/d/17cljhZnAiQTL9yzhZ_INxKx131LUzNs2paP2kCCgljo/edit#heading=h.uosl2b838wbg Book of Snowblossom - Braid]

== Voting ==

* Passes when 1000 blocks pass containing 25% voting and >50% agreement
* Pools will represent their miners.
* Set in your miner or pool configuration file either
** <code>vote_yes=5</code>
** <code>vote_no=5</code>

== Status ==

These changes have been in testnet and various smaller scale networks for months. It seems to be very stable.

* Testnet - https://test-b.snowblossom.org/ https://test-b.snowblossom.org/static/shard-visual.html
* Shardtest - https://snow-testshard.1209k.com/ https://snow-testshard.1209k.com/static/shard-visual.html

Both of those networks upgraded from a single shard to multiple shards based on load as expected.

== Things Not Complete ==

After the update, then after enough load to trigger shard creation then clients may need to connect to multiple nodes to get a full view of the network. This code is not yet complete.

Also, there are some improvements that need to be made to the explorer to show reasonable summary of all the shard status.

== Risks ==

The version 2.0 block syncing uses some new operations that only exist in 2.0 so nodes can only do a full block download from 2.0 nodes. On the plus side, with the new peer information the 2.0 nodes will automatically find each other. So as long as there are a few 2.0 nodes, it will be fine. And the on disk database is compatible so upgrading a node is simply running the new version.

== Timeline ==

If approved, the activation height will be set to be about 90 days from the acceptance vote to allow for updates.

== Node Operator Required Actions ==

By the block height that we define, all nodes will need to be updated to snowblossom 2.0 or later to validate blocks. The block header format will switch to version 2 at that point and only version blocks will be valid.

Even after shards are triggered, is based on block size average (so is not expected to by any time soon) without an configuration changes each node will just follow all shards so not changes are required.