2018-05-03 Developer Products Engineering Meeting

Date/Time: 2018-05-03 @ 13:15 UTC / 09:15 EDT / 21:15 HKT
Click here to convert to your time zone
Length: 45 minutes
Meeting link: https://zoom.us/j/351130688

This meeting is for issues around our developer facing products such as blockstack.js and the mobile SDKs.


Please reply to this forum post with items you would like included on the agenda.

Each item should include:

Item name
Background information: Links to github issues, forum posts, etc with background information on the item
Desired outcome: what decision or deliverable would you like from the discussion of this topic at the meeting?

We’ll save ~10 minutes or so for community questions or comments at the end of the meeting.

Item Name – Adding signature verification to blockstack.js storage routines.
Background Information – We currently use ECIES encryption, which authenticates the encrypted data, but does not sign it — meaning that a malicious gaia store could serve inauthentic data. This is not great.

Proposal – On putFile, add an ECDSA signature to the encrypted object – if it is present, getFile will authenticate it. We can add a keyword argument validate to getFile, which forces the authentication. This makes the change backwards compatible, however, we should encourage applications to use validation in the future, and should consider eventually defaulting validate: true in getFile in a future version.

Desired Outcome – Feedback on this plan, plus I’d like someone to commit to reviewing a PR on it in the near-term (probably @jude). This won’t be terribly difficult to add, but I’d want to get another set of eyes on it, and we should ship this sooner rather than later.

2018-05-03 Developer Products Engineering Meeting



Adding signature verification to blockstack.js storage routines.

  • Currently an imposter Gaia hub could serve inauthentic
  • Jude: constants that are strategies instead of configurations
  • We’re going to do two writes, with the signature data to different files and succeed on two 200s

React Native Support on iOS

  • Developers are trying to use React Native and having trouble with our iOS SDK
  • Ken will get on call with the developers to help them out

Hi, everyone,

It’s indeed a very good and necessary idea to implement ECDSA signature alongside the ECIES encryption scheme already present.

However one must be careful to implement it in the best secure way.

Let’s assume Alice is encrypting the file towards Bob’s Gaia hub (not sure it’s the right term here).
As it the proposal is written now, it says “signs the encrypted object”, I guess it means signing the tuple ( Ciphertext, IV, MAC, EphemerealKey ). Unfortunately, this allows for an attacker (let’s call it Eve :slight_smile: to simply strips off the signature, re-signs the tuple under his own private key and sends it again to Bob. Bob would verify the signature and allows the decryption, henceforth allowing Eve to resend that message as many times as she wishes. It can be very problematic for some use case as you can imagine.

Usually, the de-facto standard is to sign-then-encrypt as the following:

  • signs the message s = sign(m)
  • appends the signature to the message m' = m || s
  • encrypt the new message c = ECIES(m')

Unfortunately, there’s still one potential attack: this opens up the possibility of Bob decrypting the ciphertext, and resending it to third party, let’s say Charlie. Charlie would receive a correctly encrypted message signed by Alice, which is not the intended case. The problem here is that the symmetric encryption does not authenticate who’s the sender since Alice generates an ephemeral key for each new encryption.

There’s multiple solutions to this problem, which are discussed at length by Dave Davis in this page. In our case, two makes the most sense:

  • Including the recipient’s name (here public key) into the message and do sign-then-encrypt
  • Do a double signing: sign-then-encrypt-then-sign.

I think the first approach is simpler in the sense that the message would be stg like m' = m || recipient || signature. The second approach touches less parts of the message but it requires double signing on the client’s side.
In any case, I strongly recommend the sign-then-encrypt approach with one of the above two solutions.
My 2 cents: go with sign-then-encrypt with the recipient’s public key included in the message.

For the sake of completeness, it’s also possible to use the paradigm: encrypt-then-sign-then-encrypt. So the message would stay the same, no need for stripping information, but it requires a double encryption and signing on the client’s side which may impair performance quite a lot.

I’d be happy to discuss more with you guys, and to help / provide implementation if my time permits it.

Cheers !

1 Like

Thanks for the reply @nikkolasg

As you say, and the linked article details, there’s issues both with simple sign then encrypt and encrypt then sign. However the problems with encrypt then sign that you mention require that Eve be able to trick Bob into believing that her attack public key is Alice’s public key.

We don’t have that problem, because the Blockstack Naming System is a PKI— there’s no way for Eve to convince Bob that she has Alice’s public key, because Bob can lookup Alice’s public key in BNS.

I have shared this guide with @xan. Upon reviewing the posts in this forum I thought it best to include it in this thread.

If I understand the true purpose of a versioning platform like Github - the more a project is able to make the community friendly to supporters of open source, the more value can be realized by all.

Additionally, I would suggest investigating how the project can become a part of this url. Maybe Github’s technique for generating this page could be the replacement for the current directory of existing and future blockstack app projects.

Yes, Eve cannot make Bob believe that it was Alice that sent Eve’s message.

Nevertheless, Eve can send the same message Alice sent to Bob, without her knowing the message. Since Eve does not have to guess the message at random, the security of the scheme is still lowered.

It may be fine in most cases that’s true but there’s some cases when it must be avoided. Imagine the following:

Alice sends to an app / user a message saying

you can put my public key inside the list of admin public keys , because I know the password 123456789’.

In this case, Eve can send the message by herself (by stripping the signature and signing with her private key) and the recipient will then put Eve’s public key in the list of admin public key, while Eve does not know the password. In this example the app uses the public it knows from the sender of the message, it does not have to be included in the message itself.

I agree that it may not be the most regular case, but it would not be surprising that an app one day could work this way.

Anyway, I don’t want to refrain you from putting signatures, just wanted to make it clear that there is still a certain class of attacks that are left unsolved with the current proposal.

Your example made me think of this interactive guide to human networks.

I understand your reasoning behind the machine logic however, are you balancing your approach based on a human perspective? In my years of doing tech support, end-users rarely adapt technology as engineers predict.

How to Hack an Engineer

Super nice link for the interactive guide !! I really enjoyed it, thanks for sharing!

In general, you develop a functionality/product and think users will stick to that functionality, even though in practice it rarely does not as you mention it. So you might envision a few scenario of what users can do and try to protect against that. In cryptography, generally you go a little bit further: you develop a protocol and proves that it is secure against “all kinds of attacks” (note the quotes here, it’s a bit more complex), some that you have not even imagined. Then you can say that whatever the user is doing, the scheme is still “secure” (under the given assumptions about the attacker). So we indeed want to be able to envision a scheme secure against all type of user activity!

1 Like

My hopes for this project is being able to involve jr developers early in. I believe education is more positive or proactive against penetration. The idea being, the more a person’s future is positively impacted by the success of a new technology, the more they will protect its growth.

Additionally, the more “non-tech” people who can understand and participate in the creation of the platform - the higher probability your tech will be adopted as standard.

Read Nir Eyal’s analysis of Google vs. Bing adaption.

1 Like