Hiya, Yes, the AES algorithm has a block size of 128 bits (16 bytes), so the encrypted output will be a multiple of that. Any final block less than the block size will be 'filled out', i.e. padded, according to the crypto PaddingScheme, which is PKCS5 by default.
Note however, that Shiro's encryption defaults (for CipherServices anyway) automatically generate an Initialization Vector and prepend it to the output (this is pretty much necessary for proper security: no IVs = easier-to-break crypto). The default Initialization Vector size is also 128 bits for AES, so your encrypted output size will be (IV bytes.length + encrypted bytes.length). This result mod 16 should equal zero. The resulting byte array can be stored however you wish. BINARY or BLOBs are valid. Another way is to call ByteSource.toBase64() on the encrypted output and store the resulting string in a VARCHAR or CLOB column. Of course the latter approach requires more computation, but depending on your data store, could be a desirable approach. Also note that because IVs are prepended by default, it is assumed that whatever is performing the decryption knows how to 'slice off' the IV to reference it appropriately. Shiro does this of course, but if you have something else that needs to decrypt Shiro's encryption output, keep that in mind. HTH! -- Les Hazlewood CTO, Stormpath | http://stormpath.com <http://www.stormpath.com/> | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood blog: http://leshazlewood.com stormpath blog: http://www.stormpath.com/blog<http://www.stormpath.com/blog/index> On Wed, Jun 20, 2012 at 1:35 PM, drmike01 <[email protected]> wrote: > Quick question (hopefully). I'm planning on using the crypto modules to > encrypt some fields in my database (MySQL) using AES-256. My understanding > of doing this for standard Java crypto is that it encrypts in 16-byte > blocks, and so the total length of it should be, at most, the next multiple > of 16 longer than the actual data (I think it may actually be slightly > shorter than that, but that doesn't really matter to me). It also should be > stored as some BINARY or BLOB type. > > My question is whether or not the same rules apply for Shiro. The JavaDoc > doesn't mention it, although it makes sense that it would because it's > making the same sort of changes to the underlying data. > > Thanks in advance! > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Size-of-encrypted-text-tp7577530.html > Sent from the Shiro User mailing list archive at Nabble.com. >
