Labs/Secret - Revision history

Mhanson: /* Use Cases */

2011-01-03T18:01:28Z

Use Cases

← Older revision		Revision as of 18:01, 3 January 2011
Line 76:		Line 76:
	;Signing legal documents in Korea/China		;Signing legal documents in Korea/China
	* Requirements TBD		* Requirements TBD


			* Discussion on the W3C Public Webapps list of the need for such an API:
			http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1040.html

	= Features =		= Features =

Thunder: /* Related Work */

2010-07-21T21:45:29Z

Related Work

← Older revision		Revision as of 21:45, 21 July 2010
Line 134:		Line 134:
	* X509		* X509

	= Related Work =		= Related Work =

	;Other JS crypto libraries that are out there		;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.		*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		*AES and SHA-1: http://www.movable-type.co.uk/scripts/aes.html , http://www.movable-type.co.uk/scripts/sha1.html

			<br>

	;Big-Integer libraries (for RSA, (EC)DSA, DH)		;Big-Integer libraries (for RSA, (EC)DSA, DH)

	* jsbn: http://www-cs-students.stanford.edu/~tjw/jsbn/		*jsbn: http://www-cs-students.stanford.edu/~tjw/jsbn/
	* http://www.leemon.com/crypto/BigInt.html		*http://www.leemon.com/crypto/BigInt.html

	;python-ecdsa		;python-ecdsa

	http://github.com/warner/python-ecdsa		http://github.com/warner/python-ecdsa

	(I wrote the OOPish API to an existing python ECDSA library).		(I wrote the OOPish API to an existing python ECDSA library).

	The README probably covers everything we talked about, although the unit		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.
	tests (in ecdsa/test_pyecdsa.py) and the utilities in ecdsa/util.py
	would show more about the alternate forms of signatures.

	;python-curve25519		;python-curve25519

	http://github.com/warner/curve25519-donna/blob/master/python/test_curve25519.py		http://github.com/warner/curve25519-donna/blob/master/python/test_curve25519.py

	(I wrote this API and python binding to an existing C library)		(I wrote this API and python binding to an existing C library)

	The curve25519 code has Private() and Public() key objects, and the main		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.
	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		;test_rsa.py / test_aes.py

	http://allmydata.org/trac/pycryptopp/browser/pycryptopp/test/test_rsa.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		We use pycryptopp in Tahoe (Zooko wrote it). The RSA interface is very close to my python-ecdsa library.
	close to my python-ecdsa library.

	http://allmydata.org/trac/pycryptopp/browser/pycryptopp/test/test_aes.py		http://allmydata.org/trac/pycryptopp/browser/pycryptopp/test/test_aes.py

	This is the AES-CTR interface that I prefer: cryptor = AES(key), then		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:
	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 = AES("key") ; c2 = AES("key")
	c1.process("foo")+c1.process("bar") == c2.process("foobar")		c1.process("foo")+c1.process("bar") == c2.process("foobar")

	There's an extension that I want to see, to let you do random-access		There's an extension that I want to see, to let you do random-access processing:
	processing:

	c = AES(key, offset=0)		c = AES(key, offset=0)
	out = c.process(in, offset=None)		out = c.process(in, offset=None)

	(if you don't specify offset= in the .process call, it defaults to using		(if you don't specify offset= in the .process call, it defaults to using the internally-incremented counter)
	the internally-incremented counter)

	;hashlib (Python Standard Library)		;hashlib (Python Standard Library)

	http://docs.python.org/library/hashlib.html		http://docs.python.org/library/hashlib.html

	h=hashlib.sha256(data1) ; h.update(data2); out=h.digest()		h=hashlib.sha256(data1) ; h.update(data2); out=h.digest()

			<br>

			'''webcrypto-api'''<br>

			[http://html5.creation.net/webcrypto-api/ html5.creation.net/webcrypto-api/]<br>

			By Channy Yun. More limited than what we are proposing here, but we should reach out.<br>

	= Notes =		= Notes =

Gkanai: /* Use Cases */

2010-07-20T07:34:31Z

Use Cases

← Older revision		Revision as of 07:34, 20 July 2010
Line 73:		Line 73:
	;Signing legal documents in the EU		;Signing legal documents in the EU
	* Requires smartcard support		* Requires smartcard support

			;Signing legal documents in Korea/China
			* Requirements TBD

	= Features =		= Features =

Mhamburg: /* Mid Level */

2010-07-16T03:04:06Z

Mid Level

← Older revision		Revision as of 03:04, 16 July 2010
Line 96:		Line 96:
	* Algorithms: AES		* Algorithms: AES
	* Modes: CBC, CTR, (XTS? EAX?)		* Modes: CBC, CTR, (XTS? EAX?)
			[ Mike: I suggest that at least one AEAD mode (probably EAX) be included and used prominently. Except for interoperability concerns, there's not much reason to use unauthenticated crypto. ]


Line 112:		Line 113:
	* PBKDF2		* PBKDF2
	* Smartcard/token (?)		* Smartcard/token (?)


	;Key exchange		;Key exchange
	* J-PAKE		* J-PAKE


	=== High Level ===		=== High Level ===

Mhamburg: /* Use Cases */

2010-07-16T03:00:52Z

Use Cases

← Older revision		Revision as of 03:00, 16 July 2010
Line 53:		Line 53:

	;Encrypted mail (decryption in content)		;Encrypted mail (decryption in content)

			;Authentication
			* Enterprises
			* Banking
			* Requires "TPM-like" functionality

			;Authorization
			* Banking
			* Requires secure UI

			;Password managers and similar apps in the cloud

			;Password-authenticated key exchange
			* Somewhat narrow applications in the existing web

			;Cross-domain AJAX requests on federated servers
			* Eg, some kind of cryptographically signed open federated Facebook pipe dream

			;Signing legal documents in the EU
			* Requires smartcard support

	= Features =		= Features =

Warner: add notes from talk with Prof. Boneh

2010-07-03T21:30:30Z

add notes from talk with Prof. Boneh

← Older revision		Revision as of 21:30, 3 July 2010
Line 183:		Line 183:
	* day one: [[media:One-1.jpg\|left]] [[media:One-2.jpg\|middle]] [[media:One-3.jpg\|right]]		* day one: [[media:One-1.jpg\|left]] [[media:One-2.jpg\|middle]] [[media:One-3.jpg\|right]]
	* day two: [[media:Two-1.jpg\|left]] [[media:Two-2.jpg\|middle]] [[media:Two-3.jpg\|right]]		* day two: [[media:Two-1.jpg\|left]] [[media:Two-2.jpg\|middle]] [[media:Two-3.jpg\|right]]

			== Suggestions from Prof. Dan Boneh ==

			For high-level symmetric operations, the only sane things to want are authenticated encryption and message authentication. For the former, you want to offer two functions: one takes a key and a message, the other take a key, a message, and a nonce. (the first function create a random nonce). The nonce must never be re-used, and this can be accomplished with either a large random number or a simple persistent counter.

			The authenticated encryption function should be implemented with something like GCM over AES (allowing the user to choose 128/192/256 bit keys). The output should include a short magic number and a version number. Obviously if the two-argument form is used, the output must also include the nonce.

			Other notes: RSA is fading out, since factoring techniques are getting better and making keys longer and longer is a drag. ECC is the new standard.

			Low-level functions should be sufficiently hard to use that most developers will stick to the high-level encrypt/decrypt functions and not assemble the low-level pieces in unsafe ways. Consider leaving out CBC mode altogether, forcing developers who really need it to write their own. Provide low-level pieces for everything that needs to be done in native code (for performance). That probably means SHA256, AES, bigints, ECC math, GCM.

			== Brian's thoughts ==

			Boneh's simple encrypt/decrypt functions probably need some extra arguments to deal with the unfortunate world of JS unicode (non-binary) strings. One idea: allow the encrypt() function to accept either a bytestring or a unicode string, doing a utf-8 encoding on the latter, but include a bit in the output ciphertext that tells the decryptor whether to decode back into unicode or not (so the output of decrypt(encrypt(m)) is always the same type as m). We must decide whether the key is input as a 16/24/32-byte binary string, or base16/32/64-encoded into a unicode JS string. We must also decide if the output ciphertext is returned as a bytestring or gets base16/32/64 encoded into a JS string.

			So maybe add a property bag to the arguments, with fields like "key-encoding", "output-encoding", and "input-encoding".

			Keys: we should probably also provide an arbitrary-JS-string-to-key conversion function, maybe PBKDF2 (but I'm not sure the password-strengthening parts are always appropriate). The function would have two purposes: one is simple type conversion (utf-8 encode the unicode string into a bytestring, hash the arbitrary-length bytestring into a fixed-length AES key), the second is key-strengthening busywork.

			Versioning: the xxx.Crypto.Simple.encrypt() function will implicitly create messages with the most recent version of this scheme. A version= field in the property bag can be used to create messages with an older version. The ciphertext will embed the version number. The receiving xxx.Crypto.Simple.decrypt() function will handle messages constructed by older versions. Some other function will tell you the version number that's embedded in a given message (so you could choose to reject known-broken old versions, for example). Something like xxx.Crypto.Simple.version would tell you the current version number. The idea is to make things very simple for developers, but make it possible to improve the default encryption scheme later and still have a chance of compatibility.

			The presence of a nonce in the output stream should be indicated with a version bit too, or the nonce should always be included. There is a simplicity versus overhead tradeoff here. We always need the three-argument form of encrypt() because otherwise we can't get deterministic encryption, which will make known-answer unit tests impossible to write. Also, the two-argument form should still take an optional argument to control the entropy source used to generate the nonce, again to allow repeatable unit tests.

Thunder: /* Drivers */

2010-06-23T16:16:57Z

Drivers

← Older revision		Revision as of 16:16, 23 June 2010
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 =

Warner: /* Related Work */

2010-06-22T23:51:17Z

Related Work

← Older revision		Revision as of 23:51, 22 June 2010
Line 109:		Line 109:

	* 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.		* 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

Warner at 22:38, 22 June 2010

2010-06-22T22:38:59Z

← Older revision		Revision as of 22:38, 22 June 2010
Line 169:		Line 169:

	h=hashlib.sha256(data1) ; h.update(data2); out=h.digest()		h=hashlib.sha256(data1) ; h.update(data2); out=h.digest()

			= Notes =

			Whiteboard pictures:

			* day one: [[media:One-1.jpg\|left]] [[media:One-2.jpg\|middle]] [[media:One-3.jpg\|right]]
			* day two: [[media:Two-1.jpg\|left]] [[media:Two-2.jpg\|middle]] [[media:Two-3.jpg\|right]]

Thunder: /* Related Work */

2010-06-22T20:52:33Z

Related Work

← Older revision		Revision as of 20:52, 22 June 2010
Line 106:		Line 106:
	= Related Work =		= Related Work =

	Other JS crypto libraries that are out there:		;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.		* 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.


	Big-Integer libraries (for RSA, (EC)DSA, DH):		;Big-Integer libraries (for RSA, (EC)DSA, DH)

	* jsbn: http://www-cs-students.stanford.edu/~tjw/jsbn/		* jsbn: http://www-cs-students.stanford.edu/~tjw/jsbn/
	* http://www.leemon.com/crypto/BigInt.html		* http://www.leemon.com/crypto/BigInt.html

	~~Other related work with comments, this list needs editing:~~		;python-ecdsa

	~~python-ecdsa:~~ http://github.com/warner/python-ecdsa		http://github.com/warner/python-ecdsa

	(I wrote the OOPish API to an existing python ECDSA library).		(I wrote the OOPish API to an existing python ECDSA library).