SBC Coin White Paper

/// SBC GROUP
SBC Group is a leading financial investment company focusing on cryptocurrency trading, mining, forex trading ,consulting, educating and analyzing. It is first established under the SBC Trading Company umbrella headquartered in Texas, United States. Over the past 2 years, SBC group has grown from a small cryptocurrency trading community into a large-scale enterprise focusing on building a healthy and advanced cryptocurrency ecosystem. Our ultimate goal is to empower both traders and miners with end-to-end products and services that enlarge the cryptocurrency future vision Changing the way transactions are made.
Group companies include:
   SBC Trading Company
   SBC Mining Company
   SBC Consulting Company
   SBC Academy
   SBC Laboratory (R&D Center)
Long-term vision
   Become a major exchange platform for altcoins
   Build the next big wave of altcoins
   Disrupt the genesis of altcoins
   Transform digital currency from non-physical to physical
   Provide beneficial form of trading and mining without large investment
   Create a community payment system for customer needs
   Establish a ground-breaking Research and Development for continuous invention
/// SBC DEVELOPING TEAM

/// SBC COIN HISTORY
Amidst the booming growth of cryptocurrency market around the world, SBC Group has dived deeper into both trading and mining activities to learn, experiment, trade and earn insightful knowledge of the cryptocurrency market. After more than 2 years of endless development and transformation, SBC Group finally decided to release the very first generation of SBC Coin which is built upon innovative multiple hash algorithms and advanced blockchain technology.
/// SBC COIN ROADMAP

https://www.sbccoin.io/control/model/images/bg/road-map.jpg

/// MULTIPLE HASH ALGORITHMS
Recent attacks to currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation. SBC Coin is concurrently tested on the design of Multiple Hashing Algorithms published by Intel Company.
Overview
Cryptographic hashes such as MD5, SHA1, SHA256 and SHA512 are expensive in terms of computation on general purpose processors. They work on a single buffer of data sequentially, updating a hash digest state with the computations derived from each data block, using a number of rounds of processing that are dependent on each other. The sequential processing of the blocks of a single buffer seriously limits the performance on modern processors. Methods such as multi-buffer processing using vector Single.
Instruction Multiple Data (SIMD) units have been proposed for better performance on usages where it is possible to work on multiple independent data buffers. However, these are not applicable to usages of hashing a single buffer. Tree hashing has been around for many years; however, its usage has generally evolved to be thought of across multiple cores or engines. We aim to take the concepts of tree hashing and apply them to the goal of the highest possible performance on a single buffer in a single thread of a single core of a modern microprocessor.

$In this white paper, we describe a set of extensions to existing or future cryptographic hash algorithms that can achieve multi-buffer performance on a single buffer at comparable security strengths of the underlying hash algorithm, and generate a (different) digest of the same size as the original hash algorithm. The performance gains will be roughly proportional to the SIMD data-path width of the processor.
Some critical usages that require fast hashing of a single buffer are:
   Secure loading of files during boot/resume of a system
   Streaming applications where it is infeasible to buffer many streams for later processing
The basic idea behind Multi-Hash is to treat the single buffer as a set of interleaved independent buffers, which we call segments, and generate a number of independent hash digests for those segments in parallel. We use the notation xi to denote treating the data buffer as a set of i interleaved segments, where i > 0. It is expected that for efficiency i will be a power of 2.
The set of digests from the parallel segments are then hashed to form a final digest of the same size as the original underlying hash algorithm. The method of interleaving the data at a fine granularity is one of the main differences of Multi-Hash and current tree-hashing implementations, which tend to break buffers down into blocks or greater. This technique is meant to accelerate processing of hashing a single data buffer on a single thread of a single core of a modern microprocessor. However, the technique can easily be defined to be across multiple cores of a microprocessor for a second level of parallelism and performance.
Definition of Multi-Hash
One of the considerations in defining these extensions is how to hash a data buffer of any arbitrary length, given that the underlying hash algorithm works on blocks of a specific size (e.g. 64 Bytes). The standards that define these algorithms specify a padding scheme, whereby the buffer is typically extended with some bytes comprising a fixed pattern and the length of the buffer, to make the padded buffer the smallest multiple of the block-size.
Let us denote the hash algorithm as H, the number of parallel segments as S, the block-size as B bytes, digest-size as D bytes and width of the data words specified in the algorithm as W bytes (where B is a multiple of W).
The following proposed schemes can be considered:
1.   Pad the buffer with the fixed pattern concatenated with length until the total length is a multiple of B*S. Now we can process this buffer efficiently with S-way SIMD processing, generating S digests. We treat the set of digests as another data buffer of length S*D, and then generate a final hash of size D.
2.   We hash the largest region of the buffer whose length is a multiple of B*S, in parallel, generating S digests. We treat the set of digests concatenated with the rest of the buffer as a new data buffer, and then generate a final hash of size D.
3.   We pad each segment to its nearest multiple of B bytes, and then process that buffer with S-way SIMD processing, generating S digests. Here the per segment padding is done with the standard padding. One downfall with this approach is some segments may have a different padded length than other segments. We treat the set of digests as another data buffer of length S*D, and then generate a final hash of size D in a single buffer fashion. Other variations are possible, but not as efficient as option 1. Option 1 is therefore our primary proposal for Multi-Hash.

Multi-Hash Scheme to Extend Hash Algorithm H
Consider a hash algorithm H that is defined to work on an integral number of blocks of size B bytes each. Let us denote the associated padding function as PadH (Message, Length of Message, Block-size B), which extends the message with a pre-determined pattern and a concatenation of the message length, to the smallest length that is a multiple of B bytes. For a message M0 of length L to be hashed with a given level of parallelism S, we formally define the process of Multi-Hash as follows (where the || symbol denotes concatenation):
1.   Apply PadH(M0, L, B*S) to message M0, generating M0of length L. L is the smallest length that we can extend M0 to, that is a multiple of B*S bytes.
2.   Divide the padded message M0 from step 1 into S segments each of length L/S. The padded message M0 is divided in an interleaved fashion such that every word size W-bits of M0 is assigned to a different segment.
Each segment is represented as an array of W-bit words:
Seg0 = M0[0] || M0 || M0[2S] ||
Seg1 = M0[1] || M0[S+1] || M0[2S+1] ||

SegS-1 = M0[S-1] || M0[(2S-1)] || M0[(3S-1)] ||
Where each M0[n] is a word size W index into the padded message.
3.   Generate S leaf-level digests on the segments as Dk = H(Segk) for k=0(S-1)
4.   Create a new message M1 by interleaving the resultant digests from step 3 by every word size W-bits. Let M1 = D0
|| D1[0] || D(S-1)[0] || D1[1] || D(S-1)[(D/W)-1]. Where each Dk[n] is a word size W index into a segments digest. Generate padded M1 as PadH(M1, S*D, B)
5.   Return H(M1) For example, SHA-1 on a SIMD capable microprocessor with 128-bit registers would have the following parameter settings: B=64 Bytes, W=4 Bytes, S=4, D=20 Bytes.
Figure 1. x4 (S=4) Multi-Hash Segmentation of Message M0

Figure 2. x4 (S=4) Multi-Hash depiction of digests with padding into M1 for final hash

The method defined has benefits that tree hashing across buffers/cores/engines misses. For instance, the data aligned in memory is read directly into SIMD registers without the need for transposing. The method also allows data being streamed (i.e. from a network connection) to be fed directly into the Multi-Hash function without the need for knowing the length of the buffer at start time. One large advantage is that single thread applications do not have to be modified (other than at the hash algorithm level) to take advantage of greater performance due to parallelism.
Picking a Specific Multi-Hash Function in the Family of Extensions Protocols
The new hash functions can be ordered based on compute/security considerations, and the current (possibly ordered) list of cryptographic hash algorithms in various protocols/standards can be augmented with these extensions (e.g. SHA1x4, SHA1x8, SHA256x4, SHA256x8, ).
For usages of verifying signatures of files that are securely loaded, the signing entity has to replace the current cryptographic hashing algorithm of the chosen security (e.g. SHA256), with one of the compatible extensions that is most efficient to compute for verification. For instance, if the verifying entity has a 128-bit SIMD data-path execution unit in its processor core, and if we wanted a SHA256 strength digest, it would ideally prefer SHA256x4 (as the SHA256 algorithm is 32-bit based, on a 128-bit SIMD execution unit we can process 128/32 = 4 segments, in parallel). Thus, instead of using one of the currently used 32-bit algorithms {MD5, SHA1, SHA256}, the verifying entity would prefer {MD5 x8, SHA1 x4, SHA256 x4} respectively. MD5 is a bit unique in the sense that although we need only 4 segments from a 128-bit SIMD perspective, the algorithm has a very constrained data-dependency chain which makes it difficult to get the best throughput of execution units without additional parallelism.
One interesting challenge that arises is that there may be many verifying devices of different computation strengths, and the signing entity has to find the level of parallelism that works for the majority of its verifying devices. Our scheme does not require the server to estimate this very accurately, as we can always create a larger level of parallelism while signing, and have the verifying agents perform a multi-pass approach during verification if their SIMD or hardware capability cannot process as many segments as specified, all at once. For example, a signer can use a x4 scheme while a verifying agent could do two passes of a x2.
There could be some loss of efficiency if too many passes are needed, due to managing multiple state variables of the digests. Note that data can still be brought in efficiently in a streaming manner just once, however, the application will need to cycle though the sets of state variables. For instance, assume a client device does not have a SIMD unit at all, and needs to perform simple scalar operations to process a SHA256x4 hash. Instead of working with 1 set of SHA256 state variables (32 Bytes), it will simultaneously work on 4 such copies of state variables (128 Bytes), cycling through them as it processes words from the data buffer. This increase in state size is very small. A possible concern would be the working-set size increase associated with message schedules for a block (for SHA). If this increase in working-set size is problematic, one could choose to store 4 blocks of data and strictly work on one interleaved block at a time. Many other variations are possible, and we believe these methods will permit any device to process a parallel hash signature efficiently without undue burden.
The exception in these scenarios would be using a fixed hardware engine designed to perform the entire hash function, including padding, on a given buffer/length input. Unless the padding designed in the parallel Multi-Hash implementation was exactly the same as the hardware, the same result could not be calculated. However, if the hardware engine works on a per block basis or has a mode that does not include padding, then it can be used to perform multi-hash.
Based on the above considerations, we do not recommend always picking a very large number, such as x32 or x64. For instance, if most current devices are capable of x4, it would be reasonable to pick something like x8 to take advantage of the future possibility of increased SIMD data-path.
Performance of Multi-Hash
Multi-Hash provides a several factor performances gained for large message sizes. For workloads with buffers typically below 1KB, the parallelization benefits of Multi-Hash will start to diminish. Application or secure protocol designers can consider using the underlying hash function for small messages and use Multi-Hash for larger messages to achieve optimal performance. The Multi-Hash implementation was run on an Intel® Core i7 processor 2600. The tests were run with Intel® Turbo Boost Technology off.
Methodology
We measured the performance of the functions on data buffers of size 1 MB. We called the functions to hash the same buffer a large number of times, collecting many timing measurements. We discarded the first and last 1/8th samples, sorted the timings, and then discarded the largest/smallest quarter, leaving the remaining quarter to be averaged.
The timing was measured using the rdtsc() function which returns the processor time stamp counter (TSC). The TSC is the number of clock cycles since the last reset. The TSC_initial is the TSC recorded before the function is called. After the function is complete, the rdtsc() was called again to record the new cycle count TSC_final. The effective cycle count for the called routine is computed using: # of cycles = (TSC_final-TSC_initial).
A large number of such measurements were made and then averaged as described above to get the number of cycles. Finally, that value was divided by the buffer size to express the performance in cycles per byte.
Results
The performance of this family of hash functions is expected to be roughly the same as a multi-buffer method. In fact, it is expected to be a little better for at least the following reasons:
   No scheduling of buffers (of possibly different lengths) in a queue
   Ideal interleaved layout that permits a streaming access of data and maps directly to SIMD execution units without requiring transpose operations on the data

Figure 3. SHA-256 and MD5 Single Buffer (Blue) vs. Multi-Hash (Red) Performance in Cycles/Byte

For SHA256, it can be seen that the SHA256x4 Multi-Hash provides ~2.6X performance gain over the best SHA256 algorithm computation on a reasonably sized 1MB data buffer.
For MD5, the ideal parallelism is actually larger than the SIMD width due to the latencies of execution and tight data dependency chain of the round function. Therefore, MD5 shows ~4.4X3 performance gain with Multi-Hash (utilizing a Multi-Hash x8 as opposed to a Multi-Hash x4 that would be ideal for SHA1/SHA256).
It is interesting to observe that even with a 128-bit SIMD, SHA256 Multi-Hash performance is better than the single-buffer performance of the fastest still widely-used cryptographic hash algorithm MD5. We expect Multi-Hash performance to scale proportional to increasing SIMD data-path widths of future processors.
Security of Multi-Hash
It can be seen that our proposed method is a special case of tree-mode hashing, where, at the leaf-level we hash interleaved words of the data buffer, and in a 2nd level we hash the ordered set of hash digests. We perform padding at both levels of the tree, derived from the standard for the underlying hash function. The fan-out of the tree is S. We hypothesize that the resulting digest from Multi-Hash is at least as secure and collision resistant as the digest obtained by a direct application of the underlying hash function.
SHA-3 Candidates
In addition to the most commonly used hash functions today, Multi-Hash extensions should work for the new SHA3 candidates as well. The definition of Multi-Hash aligns closely with the tree hashing parameters outlined by the Keccak team in [5]. In [6], the Keccak team describes the tree hashing parameter values for a 128-bit data path SIMD implementation of Keccak as (G=LI, H=1, D=2, B=64, C=c=576). Trying to keep within a similar framework for Multi-Hash, the D value is equal to S, the number of segments. G would always be equal to LI, H is 1, and B would be equal to the word size in bits (e.g. 32 for SHA1/2). The chaining value, C, would be equal to digest size in bits (e.g. 256 for SHA256)
Multi-Hash and HMAC
Hash-based message authentication code (HMAC) is a mechanism for creating a message authentication code (MAC) using a cryptographic hash function with the combination of a message and secret key. Secure network connections, using protocols such as IPSec and TLS, make use of HMACs to ensure a message has been received correctly from the expected sender. In scenarios where messages may be large, performance may be improved if the HMAC is calculated in a parallel manner. Using the notation from the FIPS-198 specification, with the addition of parameter MH being an approved Multi-Hash function, we define the Multi-Hash HMAC function as follows:
1.   If the length of K=B: set K0 = K. Go to step 4.
2.   If the length of K > B: hash K to obtain an L byte string, then append (B-L) zeros to create a B-byte string K0 (i.e., K0 = H(K) || (00..00). Go to step 4.
3.   If the length of K4.   Exclusive-Or K0 with ipad to produce B-byte string: K0 ⊕ ipad.
5.   Apply H to the string generated in step 4: H(K0 ⊕ ipad).
6.   Use the final state of step 5 as the initial state for each segment in the application of MH to the stream of data text: MH(text) (e.g., the initial state variables of the underlying hash used by each segment within the Multi-Hash are set to the final state of H(K0 ⊕ ipad) as opposed to using the published initial constants). Note the initial state for step 6 may not be the actual hash result of step 5 (e.g. SHA-224, use all 256 bits of state).
7.   Exclusive-Or K0 with opad to produce B-byte string: K0 ⊕ opad.
8.   Append the result from step 6 to step 7: (K0 ⊕ opad)|| MH(text)
9.   Apply H to the result from step 8: H((K0 ⊕ opad)|| MH(text))
10.   Select the leftmost t bytes of the result of step 9 as the MAC

Figure 4. HMAC Construction with Multi-Hash

In step 6, we can define MH in two different ways. We can use MH as the two-step process that appends a single digest to the outer portion in step 8, or we could use MH as a one step process and append the S digests to the outer portion. We propose using the latter option of appending all S digests to K0 ⊕ opad in step 8.

Another alternative in the derivation of K0 is to divide the key into S chunks, and perform S different hashes in step 4 to provide a different initial state to each of the S segments in the MH of step 6.

/// SPECICATIONS
The cryptographic hash function SHA-256
General Description
SHA-256 (secure hash algorithm, FIPS 182-2) is a cryptographic hash function with digest length of 256 bits. It is a keyless hash function; that is, an MDC (Manipulation Detection Code).
A message is processed by blocks of 512 = 16 × 32 bits, each block requiring 64 rounds
Basic operations
   Boolean operations AND, XOR and OR, denoted by ∧, ⊕ and ∨, respectively.
   Bitwise complement, denoted by ¯.
   Integer addition modulo 232, denoted by A + B.
Each of them operates on 32-bit words. For the last operation, binary words are interpreted as integers written in base 2.
   RotR(A, n) denotes the circular right shift of n bits of the binary word A.
   ShR(A, n) denotes the right shift of n bits of the binary word A.
   AkB denotes the concatenation of the binary words A and B.
Functions and constants
The algorithm uses the functions:
Ch(X, Y, Z) = (X ∧ Y ) ⊕ (X ∧ Z),
M aj(X, Y, Z) = (X ∧ Y ) ⊕ (X ∧ Z) ⊕ (Y ∧ Z),
Σ0(X) = RotR(X, 2) ⊕ RotR(X, 13) ⊕ RotR(X, 22),
Σ1(X) = RotR(X, 6) ⊕ RotR(X, 11) ⊕ RotR(X, 25),
σ0(X) = RotR(X, 7) ⊕ RotR(X, 18) ⊕ ShR(X, 3),
σ1(X) = RotR(X, 17) ⊕ RotR(X, 19) ⊕ ShR(X, 10),
and the 64 binary words Ki given by the 32 first bits of the fractional parts of the cube roots of the first 64 prime numbers:
0x428a2f98   0x71374491   0xb5c0fbcf   0xe9b5dba5   0x3956c25b   0x59f111f1   0x923f82a4   0xab1c5ed5
0xd807aa98    0x12835b01    0x243185be    0x550c7dc3    0x72be5d74    0x80deb1fe    0x9bdc06a7    0xc19bf174
0xe49b69c1   0xefbe4786    0x0fc19dc6    0x240ca1cc    0x2de92c6f    0x4a7484aa    0x5cb0a9dc    0x76f988da
0x983e5152    0xa831c66d    0xb00327c8    0xbf597fc7    0xc6e00bf3    0xd5a79147    0x06ca6351    0x14292967
0x27b70a85    0x2e1b2138    0x4d2c6dfc    0x53380d13    0x650a7354    0x766a0abb    0x81c2c92e    0x92722c85
0xa2bfe8a1    0xa81a664b    0xc24b8b70    0xc76c51a3    0xd192e819    0xd6990624    0xf40e3585    0x106aa070
0x19a4c116    0x1e376c08    0x2748774c    0x34b0bcb5    0x391c0cb3    0x4ed8aa4a    0x5b9cca4f    0x682e6ff3
0x748f82ee    0x78a5636f    0x84c87814    0x8cc70208    0x90befffa    0xa4506ceb    0xbef9a3f7    0xc67178f2

Padding
To ensure that the message has length multiple of 512 bits:
   first, a bit 1 is appended,
   next, k bits 0 are appended, with k being the smallest positive integer such that l + 1 + k ≡ 448 mod 512, where l is the length in bits of the initial message,
   finally, the length l < 264 of the initial message is represented with exactly 64 bits, and these bits are added at the end of the message.
The message shall always be padded, even if the initial length is already a multiple of 512.
Block decomposition
For each block M ∈ {0, 1}512, 64 words of 32 bits each are constructed as follows:
   the first 16 are obtained by splitting M in 32-bit blocks
M = W1 || W2 || · · · || W15 || W16
   the remaining 48 are obtained with the formula:
Wi = σ1(Wi−2) + Wi−7 + σ0(Wi−15) + Wi−16, 17 ≤ i ≤ 64.
Hash computation
   First, eight variables are set to their initial values, given by the first 32 bits of the fractional part of the square roots of the first 8 prime numbers:
H1(0) = 0x6a09e667   H2(0) = 0xbb67ae85   H3(0) = 0x3c6ef372   H4(0) = 0xa54ff53a
H5(0) = 0x510e527f   H6(0) = 0x9b05688c   H7(0) = 0x1f83d9ab   H8(0) = 0x5be0cd19

   Next, the blocks M(1), M(2), ... , M(N) are processed one at a time:
For t = 1 to N
   construct the 64 blocks Wi from M(t), as explained above
   set
(a, b, c, d, e, f, g, h) = (H1(t−1), H2(t−1), H3(t−1), H4(t−1), H5(t−1), H6(t−1), H7(t−1), H8(t−1))
   do 64 rounds consisting of:
T1 = h + Σ1(e) + Ch(e, f, g) + Ki + Wi
T2 = Σ0(a) + Maj(a, b, c)
h = g
g = f
f = e
e = d + T1
d = c
c = b
b = a
a = T1 + T2
   compute the new value of Hj(t)
H1(t) = H1(t−1) + a
H2(t) = H2(t−1) + b
H3(t) = H3(t−1) + c
H4(t) = H4(t−1) + d
H5(t) = H5(t−1) + e
H6(t) = H6(t−1) + f
H7(t) = H7(t−1) + g
H8(t) = H8(t−1) + h
End for
   The hash of the message is the concatenation of the variables HiN after the last block has been processed
H = H1(N) || H2(N) || H3(N) || H4(N) || H5(N) || H6(N) || H7(N) || H8(N).
Implementation: signatures
Implement the cryptographic hash function just described. Define the class sha256 with the method:
public static BigInteger hash(byte[] M)
input: M is a chain of bytes of arbitrary length;
output: a positive integer in the interval [0, 2256), the value of the hash of M.
Test values
To check the implementation, you can use the following values, given in hexadecimal notation.
input   61 62 63
hash   ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad
input   61 62 63 64 62 63 64 65 63 64 65 66 64 65 66 67 65 66 67 68 66 67 68 69 67
   68 69 6a 68 69 6a 6b 69 6a 6b 6c 6a 6b 6c 6d 6b 6c 6d 6e 6c 6d 6e 6f 6d 6e
   6f 70 6e 6f 70 71
hash   248d6a61 d20638b8 e5c02693 0c3e6039 a33ce459 64ff2167 f6ecedd4 19db06c1
input   One million of 61
hash   cdc76e5c 9914fb92 81a1c7e2 84d73e67 f1809a48 a497200e 046d39cc c7112cd0

The cryptographic hash function SHA3 - 512
ECHO, a cryptographic hash function that offers:
   a simple and clean design,
   a high and well-understood security margin,
   support of the Intel AES instructions set, and
   a fully flexible design to support different properties with the same primitive.

High-level view of the hash function. The round function is described below.
Design
Specifications
You can download the specifications for the ECHO hash function:
   latest description document: SHA-3 Proposal: ECHO (version 2.0)
   the submission package: ECHO.zip
   original description document: SHA-3 Proposal: ECHO (version 1.0)
Round function
The round function of ECHO is echoing the AES structure. It is indeed made of:
   a BIG.SubWords transformation which applies 2 AES rounds to each of the 16 words of the state:

   a BIG.ShiftRows transformation that mimics AES's ShiftRows but on 128-bit words:

   a BIG.MixColumns transformation applies AES MixColumns to 4-tuples of bytes throughtout the state:

Security
Taking advantage of the simplicity and clarity of AES-like design techniques, various analyses using truncated differentials [1] have recently been conducted. These are particularly relevant to hash functions using AES-like techniques and it is interesting to note that the results can be divided into five distinct types:
   simple truncated differential attacks,
   rebound attacks,
   start from the middle attacks,
   super S-box attacks,
   multiple rebounds attack.
The first type was already considered during the design phase of ECHO. The second and third types of analysis, rebound attacks and start-from-the-middle attacks, were applied to ECHO. However, an inconsistency was pointed out with respect to the utilization of this technique for ECHO. The fourth and fifth types of attacks are probably the most currently effective when analyzing the security of the ECHO compression function.
The hash functions
Work by M. Schläffer claimed an attack on a 4-round reduced version of the ECHO hash function with respect to collision resistance. J. Jean and P.-A. Fouque however showed that the method exposed in is flawed in the final merging phase of the attack (with the consequence that the attack only works with probability 2-128).
The compression functions
The best semi-free-start collision attacks cannot reach more than only 4 rounds. Similarly, distinguishers for the compression function of ECHO-SP-256, ECHO-SP-512, and ECHO-256 are limited to 4 rounds, and distinguishers for ECHO-512 to 6 rounds. As in the case of the hash function, Schläffer's analysis on the ECHO compression function suffers from issues highlighted in.

The internal permutation

It is interesting to note that the full number of rounds in the internal permutation can be reached with the super S-box analysis. However, when designing ECHO the goal was not to build a seemingly-ideal 2048-bit permutation, but rather to build a secure 256-bit or 512-bit hash function. For instance, distinguishers for the internal permutation reduced to 7 rounds were already described in the package submitted to the NIST. The large internal permutation is an important component of the compression function, but so is the final convolution that provides a major contribution to the diffusion in ECHO. As a consequence, it is important to analyze the compression function in its entirety rather than to consider the internal permutation in isolation. Indeed, this is the appropriate position since the attendant proofs of security for the operational mode of a hash function require indistinguishability of the compression function.

Hardware
The ECHO hash function offers a very wide range of throughput/area tradeoffs for hardware implementations. Additionally, since the main building block is an AES round, it is particularly suited to co-exist with AES implementations.
This page gives an overview of the performance of the ECHO hash function on various type of hardware.
Quick Overview

Hardware implementation strategies
Because the ECHO hash function echoes the AES structure, there are basically two levels of throughput/area tradeoff:
   the AES round level, where it is possible to use between 1 and 16 modules for the S-box step, as well as 1 to 4 modules for the MixColumn step. Each of these modules is in turn subject to a specific tradeoff.
   the ECHO state level, where BIG.SubWords can use 1 to 32 AES round modules and BIG.Mix can use 1 to 64 MixColumns (on 32-bit inputs) modules.
Thus, hardware implementations (FPGA or ASIC) offer a very large choice of speed/area tradeoffs. In addition, it is possible to reuse the MixColumns modules of the BIG.Sub step to perform the BIG.Mix step (incurring extra cycles latency though). Eventually, it is possible to unroll the whole compression function by pipelining the BIG.Sub+BIG.Mix step.
Classes of implementation strategies can thus be represented by a 6-tuple:
(#Sbox, #MixColumns, #AESRound, ReuseMix, CompactSbox, CompactMix)
where the number of modules (the first half of the tuple) is per compression function iteration, and where the ReuseMix flag indicates if the MixColumn modules are shared between the BIG.Sub and BIG.Mix steps.
Among the wide spectrum of implementations, we find the two extremes:
   High Throughput, corresponding to (32×16, 3×16×4, 2, 0, 1, 0). The latency of the compression function iteration is lowered by pipelining all stages of BIG.Sub and BIG.Mix with minimum inter-layers FSM logic. This implementation strategy was experimented in [1], [2], and [4], resulting in interesting throughputs on Virtex 5, Virtex 6 as well as on ASICs (at the expense of a big area cost).
   Low Area/, corresponding to (1, 1, 1, 1, 1, 1). The aim is a maximum reuse of the atomic units, each unit being as small as possible. A single S-box and a single MixColumns unit are needed to implement an AES round as well as the BIG.Mix step. This strategy was implemented in [7] on a Virtex 5, resulting in a highly compact design (at the expense of a relatively reduced throughput).

Detailed FPGA performances
Here is a summary of ECHO douple-pipe performance on common FPGA platforms. For comparative performance figures with other candidates, take a look the SHA3 zoo hardware page. The FPGA sections concern high speed and low area extremes. Note that ECHO offers one of the highest throughput and one of the most compact area on FPGA.

The VHDL implementations, whenever publicly available, can be downloaded. We also provide a new implementation with very high throughput on Xilinx Virtex 5 and Virtex 6: the synthesis and mapping reports of the Xilinx ISE software are included in the source package.

Detailed ASIC performances
Here is a summary of ECHO douple-pipe performance on ASIC platforms. As for FPGAs, comparative studies with other candidates can be found on the SHA-3 zoo for high speed as well as low cost designs.

The smallest of the reported implementations of ECHO requires 60.0
KGE. We however claim that this figure is overestimated. Indeed, the authors of [6] use a (4, 65, 1, 0, 1, 0) strategy which is still far away from the (1, 1, 1, 1, 1, 1) strategy used for FPGAs in [7]. In addition, the most compact implementations of the AES (using a single S-box and a single MixColumns unit) have an area of 3.1 KG [9], but the authors use two S-boxes as well as a dedicated key expansion unit. Without those units, the area drops to roughly 1.77 KG. Obviously, ECHO additionally requires to sore the state and a (fixed) salt, a 64-bit key, a 64-bit addition unit, and some logic and counters for the FSM driving the BIG.Sub/BIG.Mix/BIGFinal units. The addition unit and the FSM logics amounts to 1.25 KG approximately and storing the state requires about 5000 bits (i.e. 30 KG since a bit on UMC 0.13 μm ASIC is 6 GE, see for instance [10]). Hence, it should be possible to implement ECHO in about 33 KG.

Software Specifications
This page gives an overview of the performances of the ECHO hash function on various platforms (the figures given below are in cycles per bytes).

Detailed software performance figures
Clicking on the platform name downloads the corresponding implementation. You can also get our full eBASH package. The performance figures in the table link to the details from the eBASH database, or from our machines when not available. Note that Cell and GPU implementations are not yet publicly available.

Compiling and running
Packages we provide are samples from the implementations submitted to eBASH. All implementations (C or assembly) embed the NIST API (i.e. the Init, Update, and Final function), and can thus be directly used with NIST API compliant software.

/// SBC COIN VALUE
SBC Coin will be available worldwide for both traders and mines. It is built upon the Bitcoin Blockchain protocols and multiple hashing algorithms. The philosophy behind this transformational approach is to ensure high security, fast speed, transparent transaction, and low cost on infrastructure investment. SBC coin features 20 second confirmation speeds and is 99% immune to fraudulent activities. The total quantity of SBC coin in the first release will be 389 million tokens valued at $1 per token. SBC Group plans to widely start introducing SBC coin on major cryptocurrency exchange platforms such as Poloniex, Kraken, CEX, Bitfinex, Bitstamp, etc., and will be permitted to float and be traded peer-2-peer. In addition, SBC Trading Company, a company member of SBC Group, has officially launched its trading platform that enables users to directly buy and sell cryptocurrencies seamlessly.
The price of SBC Coin will be determined by market forces and cryptocurrency exchange mechanism. Users will be able to buy and sell SBC Coin using cryptocurrency, debit card and SBC wallet.

Figure 1 Example of trading SBC Coin for other cryptocurrencies

/// SBC COIN VALUE GROWTH RATE

Figure 2 Example of the projected growth in SBC Coin Value over 4 years span

/// SBC TRADING PLATFORM
User may deposit money to SBC Trading Platform by any normal means, such as credit/debit card, PayPal, wire transfer etc. After the deposit, user may choose to be credited to SBC Wallet. Every payment inside the platform happens with cryptocurrencies. For the sake of the traders, SBC encourages users to use SBC Coin as their chosen currency for transactions. Withdrawal is recommended to be made in cryptocurrencies, as then it can be made free of charge. The reason for using fiat money as a means of deposit is to facilitate the mainstreaming of the platform which increases the user base and thus spreads the use of the SBC Coin from the early adopters to the majority.

/// PEER-TO-PEER EXCHANGE

/// SBC COIN WALLET
SBC Coin Wallet is a self-developed wallet available on iOS, Android, Max OS X, and Windows. Because SBC Coin Wallet is available on multiple platforms, its easy to use the same wallet or accounts across multiple devices.
SBC Coin Wallet is simple and clean UI/UX making it a good choice for SBC Coin users. SBC Coin Wallet is also a good option for businesses due to a shared account feature, which requires a certain number of users to sign each transaction. Two co-founders, for example, could create a 2 of 2 wallet where both will be required to sign each transaction.

/// SBC COIN DEBIT CARD
A SBC coin debit card allows users to spend their crypto-coins anywhere that VISA or Mastercard are accepted as a method of payment. You can use the debit card to shop online, swipe at a store, and even to withdraw cash at ATMs worldwide. A SBC coin debit card can be used in any country, as long as there is a VISA/Mastercard accepted sign displayed, and has no hidden fees.
The SBC coin debit card is simply a standard debit card in USD, EUR or GBP, that you can top up really quickly, using crypto-coins. So, if you have a lot of crypto-coins, and would like to spend them easily, this is one way to do that.
SBC coin debit cards are a dream come true for users who have access to various crypto-coins and would like to have the convenience of money on a debit card, but do not have a bank account.
SBC coin debit cards are also becoming more and more popular with people who do not want the hassle of trading their crypto-coins for cash, or moving money into their bank account before being able to spend that money. By using a SBC coin debit card, you spend your bitcoins directly, without having to exchange them first.



/// SBC MINING
How SBC Coin is generated?

How SBC coin is rewarded?

Why SBC Coin Mining?

How to start mining SBC Coin?

How much will you earn?

/// SBC COMMERCE

SBC Coin can be easily assessed as a form of payment for:
1.   Education: University, high-school, elementary, kindergarten, etc.
2.   Traveling & Tourism: Online booking, online ticket, touring package, etc.
3.   Entertainment: Music, Video, Concert, Theatre, etc.
4.   Online shopping: Amazon, Alibaba, eBay, Lazada, etc.
5.   Healthcare: Hospital and clinics
6.   Logistics: Air-freight, shipping, delivery, etc.

/// ICO TIMELINE
Initially, SBC Coin Ecosystem has been carefully designed, continuously tested and fully funded by SBC Group. In order to nurture SBC coin further in both enhanced algorithms and financial growth, it is necessary to publicize SBC coin on cryptocurrency market via Initial Coin Offering (ICO).
SBC Coin will be available at: sbccoin.io
The ICO project will be officially launched from the 1st of September at 6:00 am EDT to 29th of October 2017 at 12 pm EDT.

Taken into notice that SBC Coin is represented as eligible cryptocurrency that enforcing lawful act against scamming purpose. The number of unsold SBC Coin will be contributed to SBC Group foundation. In the case where all SBC Coins are purchased prior to the ending ICO time, investments will still be recognized in the form of cash.
The total quantity of SBC Coin available for ICO project will be 389 million coins. Due to our experimental period, SBC Mining company has successfully mined 38,9 million SBC Coins. 175.05 million coins will be offered on ICO market whereas SBC Wallet, SBC Debit Card, and SBC Trading Platform will be entitled to 10 million coins for a single ICO.
The remaining 145.05 million SBC coin will be consumed on employees, mining system, marketing, SBC Lab and SBC Academy.

/// SBC COIN BONUS

/// SBC COIN INITIAL VALUE

Period   Ideal Crowdfunding Amount   SBC Coin
Value   Ideal Number of
SBC Coins
Sep 15st 29th    $0 -$10,000,000   $1   0 - 10,000,000
Sep 30th 14th Oct    $20,000,00   $1    10,000,000
Oct 15st 29th     $8,900,000   $1   8,900,000



Total   $38,900,000      38,900,000

/// OTHER FORMS OF INVESTMENT
We accept various form of investments for those who prefer to use their own available cash or cryptocurrency in exchange for SBC Coin.
Eligible cryptocurrency as a form of investment:

Eligible fiat currency as a form of investment:

/// SBC ICO FUND SEGRERATION

/// BENEFITS
When purchasing the SBC Coin during the ICO project launch, investors will receive the following benefits
   During stage 1, investors will receive 30% of the purchased coins which can be transferred within the entire SBC coin ecosystem.
   During stage 2, investors will receive 20% of the purchased coins which can be transferred within the entire SBC coin ecosystem.
   During stage 3, investors will receive 10% of the purchased coins which can be transferred within the entire SBC coin ecosystem.
   The SBC coin can be converted into major cryptocurrencies and fiat currencies.
   The SBC coins will be substantially available through ICO
   SBC coin owner will be able to sell their SBC coin on the market at their own will right after the ICO project ends.
   If the ICO is mostly successful, the price of SBC coin will automatically increase.

Available at   sbccoin.io
ICO Project Launch 2017   Sep 15st Oct 29th, 2017
SBC Coin Initial Value   1 SBC Coin = $1
Number of SBC Coin Offered   389,000,000 coins
Number of SBC Coin Mined   38,900,000 coins
Bonus Scheme
   30% = Sep 15th 29th, 2017

   20% = Sep 30th Oct 14th, 2017
   10% = Oct 15st 29th, 2017

Accepted Cryptocurrencies   BTC, ETH, LTC, XEM, DASH, USDT
SBC Ecosystem   SBC Coin Trading Platform
   Peer-2-peer exchange
   SBC Coin Wallet
   SBC Coin Debit Card
   SBC Coin Mining
   SBC Ecommerce

Truncated and Higher Order Differentials, by Knudsen
Cryptanalysis of Grindahl, by Peyrin
The Rebound Attack: Cryptanalysis of Reduced Whirlpool and Grøstl, by Mendel, Rechberger, Schläffer, and Thomsen
Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES, by Mendel, Peyrin, Rechberger, and Schläffer
Improved Differential Attacks for ECHO and Grøstl, by Peyrin
Super-Sbox Cryptanalysis: Improved Attacks for AES-like Permutations, by Gilbert and Peyrin
Rebound Distinguishers: Results on the Full Whirlpool Compression Function, by Lamberger, Mendel, Rechberger, Rijmen, and Schläffer
Low Complexity Distinguisher for ECHO-Permutation, by Sasaki, Li, Wang, Sakiyama, and Ohta
Subspace Distinguisher for 5/8 Rounds of the ECHO-256 Hash Function, by Schläffer
A Framework for Iterative Hash Functions HAIFA, by Biham and Dunkelman
A Framework for Iterative Hash Functions: HAIFA, by Biham and Dunkelman
Private communication (June 2010), with Ideguchi and Tischhauser
Practical Near-Collisions and Collisions on Round-Reduced ECHO-256 Compression Function, by Jean and Fouque
Optimized fully unrolled and parallel compress for ECHO, by Mabrouk and Benadjila
Hardware Evaluation of SHA-3 Hash Function Candidate ECHO, by Lu, O'Neill, and Swartzlander
Implementation and evaluation of SHA-3 candidates on FPGA, by Kinsy and Uhler
SHA-3: FPGA Implementation of ESSENCE and ECHO Hash Algorithm Candidates Using Bluespec, by Ramakers and Narinx
Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII, by Kobayashi, Ikegami, Matsuo, Sakiyama, and Ohta
Developing a Hardware Evaluation Method for SHA-3 Candidates, by Henzen, Gendotti, Guillet, Pargaetzi, Zoller and Gurkaynak
A Compact FPGA Implementation of the SHA-3 Candidate ECHO, by Beuchat, Okamoto, and Yamazaki
High-Speed Hardware Implementations of BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD and Skein, by Tillich, Feldhofer, Kirschbaum, Plos, Schmidt, and Szekely
Design and Implementation of Low-area and Low-power AES Encryption Hardware Core, by Hämäläinen, Alho, Hännikäinen, and Hämäläinen
Compact Implementations of Pairings, by Van Herrewege, Batina, Kneević, Verbauwhede, and Preneel
Deloitte-Blockchain-Enigma-Paradox-Opportunity, by Deloitte
A Gentle Introduction To Blockchain Technology, by Antony Lewis
Smart Contract Bitcoin, by 99bitcoins

Risk Disclaimer: Trading SBC coin, including buying and selling, carries a high level of risk and is not suitable for all investors. The valuation of the SBC Coin represented in this whitepaper may be adjusted due to actual market situation. The high degree of leverage can work against you as well as for you. Before deciding to invest in SBC coin you should carefully consider your investment objectives, level of experience, and risk appetite. The possibility exists that you could sustain a loss of some or all of your initial investment and therefore you should not invest money that you cannot afford to lose. You should be aware of all the risks associated with SBC Coin trading and seek advice from an independent financial advisor if you have any doubts.

Source: https://github.com/sbccoin
Explorer: http://explorer.sbccoin.io/
Website: https://sbccoin.io
White Paper: https://issuu.com/stellaletoile/docs/sbc_whitepaper

StrikeBitClub

Posts

Merits