RE: HOWTO Verify Messages Between JavaScript and Java with a Graphene KeyPair

You are viewing a single comment's thread from:

RE: HOWTO Verify Messages Between JavaScript and Java with a Graphene KeyPair

View the full context

destrudo (50)in #steemdev • 7 years ago

what if someone intercepts one of the signed packets shown above?

Yea but what are the odds of that happening if dont' mind asking? all these come out a bit difficult but it's def worth the time to learn about it.

Thanks in advance!* 🙏

7 years ago in #steemdev by destrudo (50)

Sort:

alexpmorris (65) 7 years ago

there are many cases actually, for example if the data is not encrypted (ie. http versus https), or if packets are sent via email. and while it may be less likely to happen on an encrypted site, why risk leaving such a large potential attack vector open?

As such, the graphene blockchain takes it to a whole other level than even what I've described. If you'd like a better understanding of how STEEM validates transactions, @xeroc does a great job in explaining it in his post, "Steem transaction signing in a nutshell":

We notice that our operation is now part of the transaction (as part of the operations array) and that we now have a field for our signatures and an expiration. The expiration allows for transactions to expire if they are not included into a block by that time. Usually that date is about 30 seconds in the future.

Let's discuss the ref_block_* parameters a little: The ref_block_num indicates a particular block in the past by referring to the block number which has this number as the last two bytes. The ref_block_prefix on the other hand is obtain from the block id of that particular reference block.

The purpose of these two parameters is to prevent replay attacks in the case of a fork. Once two chains have forked, the two parameters identify two different blocks. Applying a signed transaction of one chain at another chain will invalidate the signature.

$0.27

2 votes