Underlying Crypto
Scott Markwell
secure implementation, but the team that developed this should have a
discussion of what ciphers/hash algos are used internally (currently).
If I have time later tonight, I'll dig into the source code and reply
to this message with that information.
Also, what are the plans to handle migrations between algos? Say a
better then brute force attack is developed for AES that makes it a
significant risk? Internally are things setup to allow a replacement
with a new algo that is more trusted?
Along the same lines of mitigation, will there be (or is there any)
support for secure random number generators?
Steve Weis
indirectly available in the Google Code wiki, but we can probably
compile it into a more accessible list. Briefly, the defaults are:
- Symmetric Encryption uses 128-bit AES-CBC with PKCS#5 padding. All
ciphertexts are signed with a 256-bit HMAC-SHA1 key. 192-bit and 256-
bit keys are also supported. The framework to drop in other operating
modes like CTR is also there, but not used yet.
- Symmetric authentication uses 256-bit HMAC-SHA1.
- Public Key Encryption uses 2048-bit RSA-OAEP
- Public Key Authentication uses either 1024-bit DSA-SHA1 or 2048-bit
RSA-SHA1.
Migrations are fairly easy, since each output is tagged with a key
identifying header. If, say, there were an AES compromise, we could
push out new keys that use a different algorithm. (This isn't exactly
how it would work with the existing key set design since they
currently use one algorithm per key set, but it is something that we
can change.)
As for secure random number generators, the Java version currently
uses the JCE's SecureRandom class. So, people can use the underlying
provider of their choice with no change to Keyczar. I don't see a need
to add an API call to access this, since it's easy enough to use
Java's. However, there might be some utilities we could build like
generating random, signed tokens. This could be useful for things like
cookies.
Thanks for your feedback. Keep it coming.
Scott Markwell
Looks very promising, congrats on this project.
Hal Finney, PGP Corporation
> - Symmetric Encryption uses 128-bit AES-CBC with PKCS#5 padding.
> All
> ciphertexts are signed with a 256-bit HMAC-SHA1 key. 192-bit and 256-
> bit keys are also supported.
you bypass SHA1 and go to SHA256. The margin of safety of SHA1 is
getting uncomfortably low.
Also, does "all ciphertexts" include public key encrypted + signed
data? Using a MAC there would be redundant.
> The framework to drop in other operating
> modes like CTR is also there, but not used yet.
> - Symmetric authentication uses 256-bit HMAC-SHA1.
Do you have a symmetric authenticate+encrypt operation? How is that
ordered (which is done first)?
> - Public Key Encryption uses 2048-bit RSA-OAEP
> - Public Key Authentication uses either 1024-bit DSA-SHA1 or 2048-bit
> RSA-SHA1.
1024 bit keys are too small for comfort these days. FIPS PUB 186-3
while technically still a draft standard has been out for two years
and defines larger DSA keys. I would suggest 2048 bit DSA as well as
RSA.
Public key authentication is more commonly known as digital signatures
(at least, I assume that is what you mean by the phrase).
> As for secure random number generators, the Java version currently
> uses the JCE's SecureRandom class. So, people can use the underlying
> provider of their choice with no change to Keyczar. I don't see a need
> to add an API call to access this, since it's easy enough to use
> Java's. However, there might be some utilities we could build like
> generating random, signed tokens. This could be useful for things like
> cookies.
project - thought I saw some mention of Python at least.
Hal Finney
PGP Corporation
Steve Weis
On Aug 12, 9:12 am, "Hal Finney, PGP Corporation"
> HI Steve - A couple of comments on the crypto:
> > - Symmetric Encryption uses 128-bit AES-CBC with PKCS#5 padding.
> What about the choice of the IV? How is that done?
> > All
> > ciphertexts are signed with a 256-bit HMAC-SHA1 key. 192-bit and 256-
> > bit keys are also supported.
>
> I think there is a typo here, 256 appears twice. I would suggest that
> you bypass SHA1 and go to SHA256. The margin of safety of SHA1 is
> getting uncomfortably low.
key. So, 128-. 192- and 256-bit AES keys are all supported, and will
have an HMAC-SHA1 key attached.
I think the use of SHA1 for HMACs is fine for the immediate future, at
least, according to NIST's recommendations. But, you make a good point
that it's not a good idea for the digital signature algorithms. We
should change that.
> Also, does "all ciphertexts" include public key encrypted + signed
> data? Using a MAC there would be redundant.
> Do you have a symmetric authenticate+encrypt operation? How is that
> ordered (which is done first)?
signature(header | ciphertext) ]. It would be nice if we could use a
one-pass AEAD mode here.
>
> > - Public Key Encryption uses 2048-bit RSA-OAEP
> > - Public Key Authentication uses either 1024-bit DSA-SHA1 or 2048-bit
> > RSA-SHA1.
>
> while technically still a draft standard has been out for two years
> and defines larger DSA keys. I would suggest 2048 bit DSA as well as
> RSA.
DSA as well.
> I am confused about whether this is specifically a Java oriented
> project - thought I saw some mention of Python at least.
the pipeline. It should be easy to extend to other languages as well
or settings as well. I'd like to explore using Google Gears for key
storage and doing crypto in the browser, or building some mobile
applications.
Arkajit Dey
I'll try to answer some of your questions.
On Tue, Aug 12, 2008 at 9:12 AM, Hal Finney, PGP Corporation
<hal.f...@gmail.com> wrote:
>
> HI Steve - A couple of comments on the crypto:
>
>> - Symmetric Encryption uses 128-bit AES-CBC with PKCS#5 padding.
>
> What about the choice of the IV? How is that done?
The IV bytes are randomly generated.
>
>> All
>> ciphertexts are signed with a 256-bit HMAC-SHA1 key. 192-bit and 256-
>> bit keys are also supported.
>
> I think there is a typo here, 256 appears twice. I would suggest that
> you bypass SHA1 and go to SHA256. The margin of safety of SHA1 is
> getting uncomfortably low.
The 192-bit and 256-bit key options refer to the size of the AES key,
not the HMAC key used to sign the AES ciphertext. The default length
for AES keys is 128 bits. Currently the only available length of HMAC
keys is 256 bits.
>
> Also, does "all ciphertexts" include public key encrypted + signed
> data? Using a MAC there would be redundant.
No, we only attach an HMAC sig for symmetric encryption (i.e. to AES
ciphertexts).
It's not just Java oriented. We currently have both a Java and Python
implementation of Keyczar. We're planning to develop and release a C++
version soon as well.
>
> Hal Finney
> PGP Corporation
Thanks for your comments and welcome to the project!
--Arkajit
> >
>
"Nothing is really work unless you would rather be doing something
else." - J.M. Barrie
"The outcome of any serious research can only be to make two questions
grow where only one grew before." - T. Veblen
Giulio Cesare Solaroli
would you be interested to add to the keyczar project also a
Javascript version of the libraries?
If this is the case, Clipperz has already implemented many of the core
crypto algorithms in Javascript and would be very pleased to
investigate how to contribute the code to the keyczar project, as we
are very interested in processing the data in a highly interoperable
way.
If this sounds interesting, just let me know.
Best regards,
Giulio Cesare
On Tue, Aug 12, 2008 at 7:30 PM, Arkajit Dey <arkaj...@gmail.com> wrote:
>
> [...]
Steve Weis
event that a flaw in an algorithm were discovered:
Keyczar keeps key metadata information that includes different status
values for each key: primary, active, and inactive. There is a wiki
entry on this: http://code.google.com/p/keyczar/wiki/KeyStatus .
Each key set has only a single primary key that is used to output new
signatures or ciphertext. Key sets may also have several active keys
that can only verify or decrypt data. Inactive are the same, but may
be permanently revoked at any time. We will also likely log warnings
when inactive keys are used.
If there were a break in an algorithm, we could push out a new primary
key with a safe algorithm. That would automatically demote any
existing primary key (which might be vulnerable) to be active. At that
point, no new signatures or ciphertexts would be generated using the
potentially weak keys, but we could still decrypt or verify legacy
data. This lets us gracefully deactive and revoke the weak keys when
we've dealt with the legacy data.
The only missing piece now is that within a key set, all keys have the
same algorithm but can have different key sizes. We can change this so
that each key set can contain keys used for different algorithms. I
add an open issue for this.
Steve Weis
implementation on top of Clipperz or other Javascript libraries. One
idea I had was to keep the actual key files in Google Gears. Then you
can pretty much do everything within the browser.
On Aug 12, 12:42 pm, "Giulio Cesare Solaroli"
> Hello Arkajit,
>
> would you be interested to add to the keyczar project also a
> Javascript version of the libraries?
>
> If this is the case, Clipperz has already implemented many of the core
> crypto algorithms in Javascript and would be very pleased to
> investigate how to contribute the code to the keyczar project, as we
> are very interested in processing the data in a highly interoperable
> way.
>
> If this sounds interesting, just let me know.
>
> Best regards,
>
> Giulio Cesare
>
Giulio Cesare Solaroli
On Wed, Aug 13, 2008 at 2:51 AM, Steve Weis <stev...@gmail.com> wrote:
>
> Hi Giulio. Yes, I'm very interested in building a Keyczar
> implementation on top of Clipperz or other Javascript libraries.
Great!!
> One idea I had was to keep the actual key files in Google Gears. Then you
> can pretty much do everything within the browser.
Why not just store all the key files on an hosting service encrypted
with a master passphrase?
I am very skeptical about requiring custom plug-ins, as this would
reduce dramatically the convenience of the system; but if you already
have some sound ideas, I would love to here them.
Steve Weis
once. A JavaScript implementation could both read encrypted keys from
the network or could read it locally from Gears.
For example, the Java implementation has an abstract Reader class that
is currently only implemented by a FileReader. We could implement
other types of readers that, say, derive a key from a password or read
it from the network. People can also extend their own proprietary
readers outside the package.
On Aug 13, 12:43 am, "Giulio Cesare Solaroli"
<giulio.ces...@gmail.com> wrote:
> Hello Steve,
Giulio Cesare Solaroli
>
> The medium of key storage is flexible and we can support several at
> once. A JavaScript implementation could both read encrypted keys from
> the network or could read it locally from Gears.
Ok. This make quite sense.
> For example, the Java implementation has an abstract Reader class that
> is currently only implemented by a FileReader. We could implement
> other types of readers that, say, derive a key from a password or read
> it from the network. People can also extend their own proprietary
> readers outside the package.
Ok. Got it.
What would you suggest as a first step to start the Javascript version
of the project?
Steve Weis
I won't have the time to devote to Javascript any time soon, but if you wanted to join as a member and work on it, you're more than welcome.
Giulio Cesare Solaroli
order to get a better understanding of the whole approach.
As soon as I will have some more spare time, I will try to arrange the
code on the Javascript subdirectory to match as close as possible the
other versions.
If anybody else is willing to start sooner, I will be pleased to
provide some insight on the Clipperz code base.
Best regards,
Giulio Cesare
Mouse
construct is...?
Steve Weis
It would let us switch the default hash function from SHA-1 to SHA-256 without having to regenerate keys. In retrospect, that's not very useful since we'd want to rotate to fresh keys anyway.