Labs/Secret: Difference between revisions
| Line 10: | Line 10: | ||
* [mailto:thunder@mozilla.com Dan Mills] | * [mailto:thunder@mozilla.com Dan Mills] | ||
* [mailto:bwarner@mozilla.com Brian Warner] | * [mailto:bwarner@mozilla.com Brian Warner] | ||
= Status = | |||
API is being worked on [[Labs/Secret/API|here]]. | |||
No add-on is available at this time, work will start in the next week or so. | |||
= Goals = | = Goals = | ||
Revision as of 16:16, 23 June 2010
Secret
The Secret library (real name TBD) is a general-purpose cryptography API and implementation for JavaScript.
Our plan is to design a modern API and first expose it to chrome JS (for browser add-ons), and later expose it to content as well.
Drivers
Status
API is being worked on here.
No add-on is available at this time, work will start in the next week or so.
Goals
- Give tools to developers
- Deliver an API
- Deliver a fast implementation of a subset of that API
- Make it possible for others to implement the API, both using native code and in pure JS
- Desirable Properties
- Good JS feel to the API
- Good error messaging
- Hard to screw up - reasonably safe defaults, good samples & docs
- Async support?
- feature-detection: give programs a way to reliably discover whether each feature is available or not, make it easy to add new features over time. Maybe tell developers to use e.g. 'crypto.v1.RSA', or add a get_version() function, or has_feature("rsa"), etc.
Non Goals
- Expose HW acceleration to consumers of this API (but HW accel could be used if the API implementor can & wants)
- Implement end-to-end high level solutions, see Features below for examples
Use Cases
- Weave
- Protecting bookmarks/user data
- Exchange credentials
- Account Manager
- Could use keys to prove ownership of an account, no passwords needed
- Using crypto to prove access to an account Petname toolbar
- Looks into SSL certs, etc
- Tahoe
- Uses symmetric crypto, and asymmetric signatures
- Encrypted mail (decryption in content)
Features
Primitives Level
- bytestring
- bigint
- (u)random (optional blocking, calls out to OS)
Low Level
- Packing
- ASN.1/DER
- Base64
- Charset conversion/encoding (UTF8, UCS2)
- HTML FileAPI FileBlob
Mid Level
- Symmetric crypto
- Algorithms: AES
- Modes: CBC, CTR, (XTS? EAX?)
- Asymmetric crypto
- RSA
- (EC)DSA
- (EC)DH
- Hashing
- Algorithms: SHA1, SHA256
- HMAC
- Key generation
- PBKDF2
- Smartcard/token (?)
- Key exchange
- J-PAKE
High Level
- High-level primitives are OK
- NaCl-style box/unbox
No plans to support any high-level implementations of particular use-cases, including:
- Cert stuff (signing, etc)
- PKCS
- SSL
- X509
Related Work
- Other JS crypto libraries that are out there
- SJCL: (http://bitwiseshiftleft.github.com/sjcl/ http://github.com/bitwiseshiftleft/sjcl) : AES (CCM,OCB2), SHA256, HMAC, PBKDF2, PRNG, bitarray. High-level encrypt/decrypt functions. BSD(2clause) or GPLv>=2.
- AES and SHA-1: http://www.movable-type.co.uk/scripts/aes.html , http://www.movable-type.co.uk/scripts/sha1.html
- Big-Integer libraries (for RSA, (EC)DSA, DH)
- python-ecdsa
http://github.com/warner/python-ecdsa
(I wrote the OOPish API to an existing python ECDSA library).
The README probably covers everything we talked about, although the unit tests (in ecdsa/test_pyecdsa.py) and the utilities in ecdsa/util.py would show more about the alternate forms of signatures.
- python-curve25519
http://github.com/warner/curve25519-donna/blob/master/python/test_curve25519.py
(I wrote this API and python binding to an existing C library)
The curve25519 code has Private() and Public() key objects, and the main API is private.get_shared_key(public), plus a few serialization methods. Curve25519 is defined in terms of bytestrings, so there aren't as many options as there are for ECDSA.
- test_rsa.py / test_aes.py
http://allmydata.org/trac/pycryptopp/browser/pycryptopp/test/test_rsa.py
We use pycryptopp in Tahoe (Zooko wrote it). The RSA interface is very close to my python-ecdsa library.
http://allmydata.org/trac/pycryptopp/browser/pycryptopp/test/test_aes.py
This is the AES-CTR interface that I prefer: cryptor = AES(key), then out=cryptor.process(in). (CTR mode is nicely symmetric: no need to distinguish between encryption and decryption). It uses a stream-like interface: to encrypt a large amount of data, you call process() multiple times:
c1 = AES("key") ; c2 = AES("key")
c1.process("foo")+c1.process("bar") == c2.process("foobar")
There's an extension that I want to see, to let you do random-access processing:
c = AES(key, offset=0) out = c.process(in, offset=None)
(if you don't specify offset= in the .process call, it defaults to using the internally-incremented counter)
- hashlib (Python Standard Library)
http://docs.python.org/library/hashlib.html
h=hashlib.sha256(data1) ; h.update(data2); out=h.digest()
Notes
Whiteboard pictures: