shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Manico <>
Subject Re: Crypto
Date Tue, 12 Mar 2013 13:25:18 GMT
Fantastic answer! Thank you Les.

First of all, the OWASP Encoder was updated and is what we consider to
be production quality. This might be a great addition to Shiro for XSS
Defense. If you need us to re-license it in any way, please just ask.

JCE's defaults are criminal. :)

I'm looking for volunteers in the crypto community to do a dig into your
work. Crypto is brutal, and assurance helps the cause. :)



> Aloha Jim - nice to see you again :)
>> I'm reviewing the Shiro crypto API's. What an excellent and simple to use abstraction!
> Glad you like it!
>> Have there been any review of Shiro's crypto by a professional cryptographer or similar
resource? Have any of those reports been made public?
> Nothing that is formal or 'white paper'ish, although we would be
> hugely appreciative of any efforts that professionals might wish to
> undertake.
> Just for clarity (although you probably know this, but I want to
> document for posterity), Shiro does not implement any cryptography
> algorithms itself.  As you stated, it is an abstraction - it 'sits on
> top' of the more complex JCE API components, implementing best
> practices with that API.  So you can use the default JCE or plug in
> something like Bouncy Castle, and Shiro will work just fine,
> delegating to the underlying JCE architecture.
>> For example, one of the creators of AES told me; "When using AES in CBC mode your
IV's really should be unique per message and the IV's should stay in secret".
> Far be it from me to contradict one of the AES authors ;)  Shiro does
> almost all of that out of the box - keeping the IVs secret is not
> something Shiro does at the moment however due to some complexity
> requirements that would impose on the Shiro end-user (please feel free
> to add a Jira improvement issue - I'd be happy to take a look at it).
> That being said, Shiro's defaults for block ciphers is *much* more
> secure than the JDK defaults.  For example, the JDK defaults to using
> AES in ECB mode and I believe no padding scheme, which is effectively
> useless.  Here is an example showing why:
> Plaintext:
> Ciphertext w/ JDK's defaults:
> Ciphertext w/ Shiro's defaults:
> The reason the JDK does this is that almost all other cipher modes of
> operation require an IV and the JDK's APIs are low level enough such
> that they can't (won't) generate an IV for you automatically.
> Shiro however does generate cryptographically strong random IVs and
> embeds them in the ciphertext output.  When decrypting, the IV is
> 'unembedded' and then used to decrypt the ciphertext.  The IV size is
> the same size as the block size to ensure no other block is
> distinguishable.  Additionally, Shiro uses a proper padding scheme to
> ensure all output remains a multiple of the block size, to
> additionally help ensure patterns are hard to distinguish.
> So while Shiro embeds the random IVs in the message and does not keep
> them secret, its default approach with secure random IVs and padding
> schemes is *much* more secure than using the JDK's defaults.
> With the exception of (few) crypto experts, almost all developers I've
> personally come across had no idea the JDK's defaults are so insecure
> and had no idea they weren't using it correctly.  At least Shiro gets
> everyone to a level of security that most wouldn't have achieved
> otherwise.
> Finally, the reason why Shiro (currently) embeds the IVs in the
> ciphertext instead of keeping them secret is one of infrastructural
> complexity that would be imposed on Shiro end users: we'd need to
> support a storage abstraction.  While this wouldn't be hard to
> incorporate into Shiro (probably just a few interfaces), it would
> probably add more confusion to an already confusing topic.
> That being said, as with all things in Shiro, we can continue with our
> sensible defaults out-of-the-box and more advanced users can simply
> turn on the storage feature.  Please open a Jira issue if you'd like
> to see this added (and as always, patches welcome! :)).
>> My apologies if I'm posting in the wrong place.
> None necessary - this is the right place :)  Thanks for the great questions!
> Best,
> Les Hazlewood
> CTO, Stormapth
> @lhazlewood

View raw message