(Encrypted) Twister Private Key Exchange Format
27 views
Skip to first unread message
Julian Steinwachs
Jan 24, 2016, 5:12:20 AM1/24/16
to twist...@googlegroups.com
For easier backup and import of twister accounts i suggest we agree on a
file format that contains the private key of an account either
(symmetrically) encrypted or in plain text. The encrypted form can be
send via email for back up, which also makes it easy to distribute it
from device to device. For twister-react this is an important feature as
localstorage isn't a reliable data store.
In principle the encrypted form could also be store on the DHT which is
also not reliable but an additional storage always reduces the risk of
data loss. Also this would make it stupid easy "log in" to twister at
any machine. It reduces the security though as people will use passwords
that are less secure than the raw bitcoin keys.
So i suggest a simple json format:
{
"username" : optional string
"encrypted" : optional bool / defaults to true
"algorithm" : optional string / defaults to "aes-256-cbc"
"payload" : string / hex encoded buffer
"iv" : string / hex encoded buffer / optional if ecpryted is set false
}
if 'encrypted' is set to false the payload is directly utf8 decoded.
Otherwise 'payload' is decrypted with the initialiation vector ('iv')
and the correct 'algorithm' and then decoded to utf8.
In both cases it yields another json string:
{
"key": string / wif format
"username": optional string
... other optional fields
}
It is important that one of the both username fields is always set or
the json is stored at a DHT resource that contains the username in its name.
For mime-type i suggest simply application+json and as fileending i
suggest .twid (twister identity).
For the DHT i would go by e.g. ["tschaul","twid","s"]
Greetings
Julian
file format that contains the private key of an account either
(symmetrically) encrypted or in plain text. The encrypted form can be
send via email for back up, which also makes it easy to distribute it
from device to device. For twister-react this is an important feature as
localstorage isn't a reliable data store.
In principle the encrypted form could also be store on the DHT which is
also not reliable but an additional storage always reduces the risk of
data loss. Also this would make it stupid easy "log in" to twister at
any machine. It reduces the security though as people will use passwords
that are less secure than the raw bitcoin keys.
So i suggest a simple json format:
{
"username" : optional string
"encrypted" : optional bool / defaults to true
"algorithm" : optional string / defaults to "aes-256-cbc"
"payload" : string / hex encoded buffer
"iv" : string / hex encoded buffer / optional if ecpryted is set false
}
if 'encrypted' is set to false the payload is directly utf8 decoded.
Otherwise 'payload' is decrypted with the initialiation vector ('iv')
and the correct 'algorithm' and then decoded to utf8.
In both cases it yields another json string:
{
"key": string / wif format
"username": optional string
... other optional fields
}
It is important that one of the both username fields is always set or
the json is stored at a DHT resource that contains the username in its name.
For mime-type i suggest simply application+json and as fileending i
suggest .twid (twister identity).
For the DHT i would go by e.g. ["tschaul","twid","s"]
Greetings
Julian
Miguel Freitas
Jan 24, 2016, 3:06:32 PM1/24/16
to twist...@googlegroups.com
Hi Julian!
I was thinking about the same lines when I tried your proxy (btw I still have not gone past logging in and seeing profile, but admittedly haven't yet had time to explore).
The simplest scenario i thought was storing the key into a file (user would carry it around in a pendrive) that we could use the html5/javascript functions to read to memory without submit.
The encryption part is a good idea, and I think we may check what others have used here in order to derive the AES-256 key from text password without making it too easy to brute force. This piece here contains some good thoughts on the subject:
So maybe the 'algorithm' field are actually two fields: (1) the encryption algo itself for payload and (2) which PBKDF is used to generate the key for algo.
About the json you suggest, they look good to me! :-)
The plaintext 'username' in your first example is also something we might want to omit. Think of this file/pendrive falling into the wrong hands: they would know the owner's username, which might be a sensitive information by itself.
I still a bit unsure about storing the whole thing to DHT. But that could be an optional scenario as well.
regards,
Miguel
Julian
--
You received this message because you are subscribed to the Google Groups "twister-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twister-dev...@googlegroups.com.
To post to this group, send email to twist...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Julian Steinwachs
Jan 26, 2016, 2:54:34 AM1/26/16
to twist...@googlegroups.com
We should probably simply piggy back onto bip38
(https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki)
which also has a scrypt option. Also there are implementations in
the relevant programming languages.
in that case there would be no json because its all contained in a bas58-encoded string.
in that case there would be no json because its all contained in a bas58-encoded string.
Benny Greschbach
Jan 26, 2016, 3:49:15 AM1/26/16
to twist...@googlegroups.com
Hi, when using a PBKDF you could store a high-entropy salt in the backup
as well. It would be fed into the key derivation function to frustrate
rainbow-table attacks (that was probably the idea of having the iv there
as well, right?).
For using the encrypted backup as a means to enable simple
username/password login, maybe some ideas of this paper by some
colleagues of mine and me could be interesting: "Passwords in
Peer-to-Peer" http://www.csc.kth.se/~gkreitz/p2ppass/
To effectively defend against offline bruteforce attacks (which, I
guess, would become quite attractive if many people store their
encrypted credentials in the DHT) something like this might be
interesting: "Memento: How to Reconstruct Your Secrets from a Single
Password in a Hostile Environment" by Camenish et al.
https://eprint.iacr.org/2014/429.pdf
Probably all their zero-knowledge-proofs are too heavy-weight to
implement on DHT nodes, but they refer to related password-hardening
protocols that might be easier to implement. The basic idea is that you
need to contact several nodes that help to transform your password into
a secret key (without them learning either) and after you did so, you
prove to all these nodes that you successfully logged in. If these nodes
get too many requests without corresponding proofs that the requester
succeeded in logging in, they rate-limit the requests to frustrate
brute-force attacks.
Cheers, Benny
> <mailto:twister-dev%2Bunsu...@googlegroups.com>.
--
Please encrypt.
PGP: 0xB66E7E91
as well. It would be fed into the key derivation function to frustrate
rainbow-table attacks (that was probably the idea of having the iv there
as well, right?).
For using the encrypted backup as a means to enable simple
username/password login, maybe some ideas of this paper by some
colleagues of mine and me could be interesting: "Passwords in
Peer-to-Peer" http://www.csc.kth.se/~gkreitz/p2ppass/
To effectively defend against offline bruteforce attacks (which, I
guess, would become quite attractive if many people store their
encrypted credentials in the DHT) something like this might be
interesting: "Memento: How to Reconstruct Your Secrets from a Single
Password in a Hostile Environment" by Camenish et al.
https://eprint.iacr.org/2014/429.pdf
Probably all their zero-knowledge-proofs are too heavy-weight to
implement on DHT nodes, but they refer to related password-hardening
protocols that might be easier to implement. The basic idea is that you
need to contact several nodes that help to transform your password into
a secret key (without them learning either) and after you did so, you
prove to all these nodes that you successfully logged in. If these nodes
get too many requests without corresponding proofs that the requester
succeeded in logging in, they rate-limit the requests to frustrate
brute-force attacks.
Cheers, Benny
> To post to this group, send email to twist...@googlegroups.com
> <mailto:twist...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "twister-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to twister-dev...@googlegroups.com
> <mailto:twister-dev...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "twister-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to twister-dev...@googlegroups.com
> To post to this group, send email to twist...@googlegroups.com
> <mailto:twist...@googlegroups.com>.
--
Please encrypt.
PGP: 0xB66E7E91
Miguel Freitas
Jan 26, 2016, 5:21:55 AM1/26/16
to twist...@googlegroups.com
Thanks Benny, very interesting references! They're on my todo list for reading.
Yes, salt for PBKDF is definitely a must. Good point.
I believe bip38 should work as well. We might look for comments and further development/usage since it's a proposal from 2012.
regards,
Miguel
To unsubscribe from this group and stop receiving emails from it, send an email to twister-dev...@googlegroups.com.
To post to this group, send email to twist...@googlegroups.com.
Julian Steinwachs
Jan 26, 2016, 1:45:59 PM1/26/16
to twist...@googlegroups.com
Interesting stuff! For now i think bip38 scratches my itch but we should
definitely stay on this topic of making the crypto more user friendly. A
big issue for me is password recovery which you also comment on. I like
the secret-sharing email-based approach. I think in Twister we could
distribute the key shards via direct messages and let the user collect
them out of band (e.g. by email) from his trusted peers. I don't see
right now how the commitment to an email address is beneficial. It can
even be harmful i think because than the peers maybe only check the
email address and not whether its actually the right person claiming the
identity. The security questions are also a really cool. Its not as easy
to set up but the restoring is less complicated.
Greetings!
definitely stay on this topic of making the crypto more user friendly. A
big issue for me is password recovery which you also comment on. I like
the secret-sharing email-based approach. I think in Twister we could
distribute the key shards via direct messages and let the user collect
them out of band (e.g. by email) from his trusted peers. I don't see
right now how the commitment to an email address is beneficial. It can
even be harmful i think because than the peers maybe only check the
email address and not whether its actually the right person claiming the
identity. The security questions are also a really cool. Its not as easy
to set up but the restoring is less complicated.
Greetings!
Reply all
Reply to author
Forward
0 new messages