I am developing a decentralized algorithm which is able to do a deterministic calculation based on input data and a given random seed.
But how to achieve a provably fair and cryptographically secure pseudorandom number generator (CSPRNG) on hyperledger ?
My first assumption was to get a random number from the consensus algorithm but a validator could manipulate the current block to his advantage if he sends the transaction only with his manipulated block.
Later I developed this algorithm which should work but is hard to implement:
for every block:
every validator:
1. generates new temporary privkey and pubkey
2. makes a raw transaction to the next validators pubkey
3. transfers his privkey to the blockchain after a block was broadcasted
4. verifies every privkey which belongs to a pubkey on the blockchain
5. calculates H(blockhash | privkey1 | privkey2 | ... | privkeyn) as new random number
I think this is really interesting for gambling applications, too.
So what is the easiest way for my problem? Should I realize the algorithm shown above?
Related
Does anyone know what's a hashgraph and the difference from blockchain? If you could explain it to me how it works, I would be pleased!
Thank you in advance!
Hedera Hashgraph is very much different from a regular Blockchain (which is a chain of blocks as its name suggests), it is a DAG (Directed Acyclic Graph).
You can read more about what a DAG is in the link provided but apart from that how Hedera is different is that it is solving the below problems that any DLT should overcome to become Scalable, Secure and Fast without losing Trust:
(1) Performance,
(2) Security,
(3) Governance,
(4) Stability,
(5) Regulatory Compliance.
How is it solving all this simultaneously without losing Trust is something that you can read more in their whitepaper which explains beautifully or refer this article from Rejolut.
One primary problem with any Public Blockchain is the TPS or Transaction per second it can handle and Hedera Hashgraph is miles ahead of the others with being able to clock 100,000 TPS which makes it valuable and preferred option as it offers services like Crypto Service, File Service, Smart Contract Service and Consensus Service.
You can have a look at some of the explorers like Kabuto and Dragonglass to get an idea of the transaction speed and other details.
If you want to play around with Hedera Hashgraph, their docs are very well written or you can use console playground to work on Smart contract and Consensus services directly and maybe use fairorder to do the account management for you to begin with.
Hedera does not use blockchain. It uses DAG, "Directed Acyclic Graph. it keeps the records of communication of all the nodes in Dag and time stamps all these messages. Sending messages between nodes is called gossiping`. Its source code is not open source.
How does the gossip protocol work
In hashgraph, when sending information between nodes, "Alice" will
choose another member at random, such as "Bob". Then Alice will tell
Bob all of the information she knows so far. Alice then repeats this
information with a different random member. Bob repeatedly does the
same, and all other members do the same. In this way, if a single
member becomes aware of new information, it will spread exponentially
fast through the community, until every member is aware of it.
The synchronization of information between two members through the
gossip protocol is called a gossip sync. Upon completion of a gossip
sync, each participating member commemorates the gossip sync with an
event. An event is stored in memory as a data structure composed of a
timestamp, an array of zero or more transactions, two parent hashes,
and a cryptographic signature. The two parent hashes are the hash of
the last event created by the self-parent prior to the gossip sync and
the hash of the last event created by the other-parent prior to the
gossip sync.
Gossiping is the basis of the hashgrap consensus algorithm which uses asynchronous byzantine fault tolerant (abft) . this indicates that there is no specific time when all the nodes reach consensus. In other words abft consensus mechanism has no block time. (there is no blockchain here. neither a block reward)
Since gossiping the fastest way of sperading information, it takes 3-5 seconds for the entire network to reach a consensus.
Hedera claims that the network achieves 10,000 HBAR cryptocurrency transactions per second. (i personally do not believe those claims)
You can also write smart contracts on Hedera. But you cannot execute 10000 smart contract operations per second because Hedera uses EVM and EVM is very slow.
Hedera has no slashing. If validators misbehave, they will not lose any of their crypto holdings. because they claim that hedera hashgraph gives validators less opportunity to misbehave. validators receive the 90% of the network fees.
I'm writing a peer to peer network protocol based on private/public key pair trust. To verify and deduplicate messages sent by a host, I use timestamp verification. A host does not trust another host's message if the signed timestamp has a delta (to the current) of greater than 30 seconds or so.
I just ran into the interesting problem that my test server and my second client are about 40 seconds out of sync (fixed by updating ntp).
I was wondering what an acceptable time difference would be, and if there is a better way of preventing replay attacks? Supposedly I could have one client supply a random text to hash and sign, but unfortunately this wont work as in this situation I have to write messages once.
A host does not trust another host's message if the signed timestamp has a delta (to the current) of greater than 30 seconds or so.
Time based is notoriously difficult. I can't tell you the problems I had with mobile devices that would not or could not sync their clock with the network.
Counter based is usually easier and does not DoS itself.
I was wondering what an acceptable time difference would be...
Microsoft's Active Directory uses 5 minutes.
if there is a better way of preventing replay attacks
Counter based with a challenge/response.
I could have one client supply a random text to hash and sign, but unfortunately this wont work as in this situation I have to write messages once...
Perhaps you could use a {time,nonce} pair. If the nonce has not been previously recorded, then act on the message if its within the time delta. Then hold the message (with {time,nonce}) for a windows (5 minutes?).
If you encounter the same nonce again, don't act on it. If you encounter an unseen nonce but its out of the time delta, then don't act on it. Purge your list of nonces on occasion (every 5 minutes?).
I'm writing a peer to peer network protocol based...
If you look around, then you will probably find a protocol in the academic literature.
For a personal MMO game project I am implementing a homebrew reliable UDP-based protocol in java. Given my current setup I beleive it would be relatively simple for a snooper to hijack a session, so in order to prevent this I am taking the opportunity to learn a little cryptology. Its very interesting.
I can successfully create a shared secret key between the client and server using a Diffie-Hellman key exchange (a very clever concept), but now I need to use this to guarantee the authenticity of the packets. My preliminary testing so far has shown that the couple of different ciphers Ive tried bloat the amount of data a bit, but I would like to keep things as small and fast as possible.
Given that I am only trying to authenticate the packet and not nessecarily conceal the entire payload, I have the idea that I could put an 8 byte session ID generated from the secret key into the packet header, encrypt the whole packet, and hash it back down to 8 bytes. I take the unencrypted packet and put the 8 byte hash into the place of the session ID and then send it off.
Would this be secure? It feels a little inelegant to encrypt the whole packet only to send it unencrypted - is there a better/faster way to achieve my goal? Please note I would like to do this myself since its good experience so Im not so interested in 3rd party libraries or other protocol options.
If both peers have access to a shared secret (which they should, since you're talking about Diffie-Hellman), you could simply store a hash of the datagram in its header. The receiver checks to see if it matches.
As an added security measure, you could also add a "challenge" field to your datagram and use it somewhere in the hashing process to prevent replays.
So this hash should cover:
The shared secret
A challenge
The contents of the datagram
EDIT
The "challenge" is a strictly incrementing number. You add it to your datagram simply to change the hash every time you send a new message. If someone intercepts a message, it cannot resend it: the receiver makes sure it doesn't accept it.
I understand that unique IV is important in encrypting to prevent attacks like frequency analysis. The question: For AES CBC encryption, whats the importance of the IV? has a pretty clear answer explaining the importance of the IV.
Would there be any security holes in sending the IV in clear text? Or would it need to be encrypted with the same public/private key that was used to send the symmetric key?
If the IV needs to be sent encrypted, then why not generate a new symmetric key each time and consider the IV as part of the key? Is it that generating a symmetric key is too costly? Or is it to minimize the amount of data transported?
The top answer to Secret vs. Non-secret Initialization Vector states:
A typical key establishment protocol will result in both involve parties computing a piece of data which they, but only they, both know. With Diffie-Hellman (or any Elliptic Curve variant thereof), the said shared piece of data has a fixed length and they have no control over its value (they just both get the same seemingly random sequence of bits).
How do two entities derive the "same seemingly random sequence of bits" without having a shared piece of information? Is the assumption that the shared information was sent encrypted? And, if the shared information is sent encrypted, why not just send the IV encrypted?
Because an application needs to transport the symmetric key securely, it would seem that separating the IV from the key itself is essentially an optimization. Or am I missing something?
There is no security hole by sending the IV in cleartext - this is similar to storing the salt for a hash in plaintext: As long as the attacker has no control over the IV/salt, and as long as it is random, there is no problem.
The main difference between initialization vector and key is that the key has to be kept secret, while the IV doesn't have to be - it can be readable by an attacker without any danger to the security of the encryption scheme in question.
The idea is that you can use the same key for several messages, only using different (random) initialization vectors for each, so relations between the plain texts don't show in the corresponding ciphertexts.
That said, if you are using a key agreement scheme like Diffie-Hellman, which gives you a new shared secret for each session anyways, you can also use it to generate the first initialization vector. This does not really give much security advantages compared to choosing the initialization vector directly and sending it with the message, but saves some bits of bandwith, and some bits of entropy from your random source. And it makes the IV a bit more random in case that one of the partners has a bad randomness source (though DH is not really secure in this case, too).
How do two entities derive the "same seemingly random sequence of bits" without having a shared piece of information?
Is the assumption that the shared information was sent encrypted? And, if the shared information is sent encrypted,
why not just send the IV encrypted?
Diffie-Hellman is based on a group-theoretic problem: Eve knows a (cyclic) group G with generator g and sees the the two values g^a (transmitted from Alice to Bob) and g^b (transmitted from Bob to Alice), where a and b are random large integers chosen by Alice and Bob, and unknown to Eve and even the other partner). The shared secret is then (g^a)^b = g^(a·b) = (g^b)^a. Obviously Bob (who knows b) can calculate the secret as (g^a)^b, while Alice (who knows a) can calculate (g^b)^a. Eve somehow needs to derive this secret to crack the protocol.
In some groups this (known as the computational Diffie-Hellman problem) seems to be a hard problem, and we are using these groups in Cryptography. (In the original DH, we use a subgroup of prime order of the multiplicative group of some large finite prime field, in Elliptic Curve DH we use an elliptic curve group over a finite field. Other groups work, too (but some of them are weak, e.g. in the additive group of a field it is trivial to solve).)
Then both Alice and Bob use a key derivation function to derive the actual keying material (i.e. encryption keys for both directions, MAC keys, and the starting IVs).
Currently I am working on an embedded project. The client side is an 8bits MCU and the server side is computer.
As part of goal, I want to minimize the chance people copy our product. During the initialization phase, the server send its serial number to client and client do some simple calculation with its serial number then send result back to server. The server checks the result to a pre-calculated, hardcoded value, if match the client is authentic.
The problem is the calculated serial number that sent back to server is always fixed. Any copycat company can figure it out quite easily with a logic analyzer. I want to make the transmitting serial number seems random bits from time to time but still be able to decrypt back to its original value. A good example using AES encryption (notice every time you press the Encrypt It button a seemingly random text is generated, but as you decrypt it, then it reverts to the original text.)
Due to ROM/RAM and process power limitation in 8bits MCU I can’t fit a complete AES routine in it, so AES is out of a solution. Is there an easy and efficiency algorithm just to randomize the transmission?
Use a key pair. On initialization:
Client tells server "I am online"
Server encrypts a verification message, which only the client will be able to decode
Client sends back the decrypted message
There should be no need for the server's key to be hardcoded - it can be generated based on a timestamp (only an answer within an acceptable range is accepted) or the codes can be generated on an as-needed basis with a timeout to prevent them from being stored for a long term.
Have the server send either a monotonically-increasing counter or a timestamp to the client, alongside the serial number. The client then includes that in the calculation it performs.
Because the server always sends a different request, the response will always be different (of course, if the market is lucrative enough your competitors can always disassemble your MCU code and figure out how to replicate it, but there's really no stopping that).
A different idea might be to require the 8 bit controller to send a CRC of the date, time and serial number to the server. The server can verify it is a unique serial and send a CRC with date, time and authorization code.
You might also look into the rolling code algorythms used for garage doors openers to see if they could be applied to your application.