Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add signable representations #1666

Merged
merged 5 commits into from
Jul 15, 2020
Merged

Add signable representations #1666

merged 5 commits into from
Jul 15, 2020

Conversation

nc6
Copy link
Contributor

@nc6 nc6 commented Jul 15, 2020

No description provided.

nc6 added 3 commits July 15, 2020 12:20
We use this in place of the tuple previously. We now have full control
of how this is serialised for signing.
@nc6 nc6 requested a review from dcoutts July 15, 2020 10:21
To construct the SignableRepresentation for OCertSignable, rather than
manually appending bytestrings created in different ways.
@nc6 nc6 force-pushed the nc/signableRep branch from 3417d4d to c378d16 Compare July 15, 2020 10:34
Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good generally, just the OCert that's a bit squiffy

Comment on lines 149 to 150
<> BSL.toStrict (Binary.encode counter)
<> writeBinaryWord64 (fromIntegral $ unKESPeriod period)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two should both be at-most 64bit numbers, so we should serialise them the same.

tbh, we should probably use Word64 for the cert counter not natural.

@nc6
Copy link
Contributor Author

nc6 commented Jul 15, 2020

@dcoutts I agree that the counter should probably be bounded, but on the basis that it's not, I'm wary of serialising it as if it is, since that allows a potential attack. Since we compare the counter, one could replay the ocert counter i with a counter of maxBound @Word64 + i, and have validation pass but be able to trump the real block

Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

We should add a TODO to use a newtype wrapper for the cert counter.

Comment on lines 146 to 149
BSL.toStrict . Binary.runPut $ do
Binary.putByteString (KES.rawSerialiseVerKeyKES vk)
Binary.put counter
Binary.putWord64be (fromIntegral $ unKESPeriod period)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bytestring builder will be faster

Suggested change
BSL.toStrict . Binary.runPut $ do
Binary.putByteString (KES.rawSerialiseVerKeyKES vk)
Binary.put counter
Binary.putWord64be (fromIntegral $ unKESPeriod period)
runByteBuilder (32+8+8) $ do
BS.byteStringCopy (KES.rawSerialiseVerKeyKES vk)
BS.word64BE counter
BS.word64BE (fromIntegral $ unKESPeriod period)

Needs

import Shelley.Spec.Ledger.Serialization (runByteBuilder)
import qualified Data.ByteString.Builder as BS
import qualified Data.ByteString.Builder.Extra as BS

@nc6 nc6 merged commit 0ecdb5d into master Jul 15, 2020
@iohk-bors iohk-bors bot deleted the nc/signableRep branch July 15, 2020 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants