5,863 reputation
2836
bio website
location Netherlands
age 40
visits member for 3 years
seen 3 hours ago

Security professional with many years of experience with the practical application of cryptographic algorithms and protocols. I'm helping with the design of protocols and API's within international standardization bodies. Lead developer of a common criteria certified product. Over 30 years of general experience with computers.

Currently looking for a new position in the Netherlands.


Nov
20
comment AES - Encrypting multiple blocks of files
If you prefix something it becomes larger? If the maximum size of the encrypted blocks can be somewhat larger than the plaintext you can just use CBC + padding or CTR and prefix the IV.
Nov
20
revised Availability of a simple limited PRNG algorithm
edited title
Nov
19
revised Encryption of big files in Java with AES/GCM
added 75 characters in body
Nov
19
revised Encryption of big files in Java with AES/GCM
added 75 characters in body
Nov
19
comment Encryption of big files in Java with AES/GCM
@archie Thanks for the warning. Note that you can always place the BC provider on top of the list of providers and have that take over, or make the provider configurable. I'll take another look at GCM as in Java 8, also because of a few updates regarding bugs with CipherInputStream. This is brand new functionality and is still a bit in movement.
Nov
19
comment AES - Encrypting multiple blocks of files
Explained this in the answer instead of a comment, I apologize if I unnecessarily complicated things, but otherwise the encryption of files is completely standard.
Nov
19
revised AES - Encrypting multiple blocks of files
added 191 characters in body
Nov
19
answered AES - Encrypting multiple blocks of files
Nov
19
comment Encryption of big files in Java with AES/GCM
In general it is better to ask runtime specific questions at stackoverflow. I've not voted to close as your actual question is not directly about the library. I've split my answer up in a theoretical and a Java specific part though (maybe other answers, if any, could do the same).
Nov
19
comment Encryption of big files in Java with AES/GCM
Beware that the tag size matters with GCM. You could think of EAX or HMAC based authentication if you don't want to look into the security of GCM.
Nov
19
answered Encryption of big files in Java with AES/GCM
Nov
19
comment DHE key exchange. Is it really secure?
@Larry I look forward to your paper where you ridicule the entire cryptographic community. Please jot me down as the idiot that ridiculed you before you proved that the crypto community is a bunch of asses :)
Nov
18
revised Is the output of AES-CBC + MAC the same size as the input?
added 25 characters in body
Nov
18
revised Is the output of AES-CBC + MAC the same size as the input?
added 176 characters in body
Nov
18
comment Is the output of AES-CBC + MAC the same size as the input?
That's called overhead and it is in the answer. I've taken the liberty to use the maximum padding size. You may bring it down to 32 bytes if you use a 8 byte tag and 8 byte input to calculate the IV. That is of course if you just concatenate everything, no additional structure specified.
Nov
18
comment Is the output of AES-CBC + MAC the same size as the input?
AES-GCM only requires one key, can use an (8 byte?) nonce directly instead of a full IV and the authentication tag size is configurable. Furthermore, it is much faster. More dangerous in use, but it has some advantages. If you want easy security with less speed advantages, use EAX mode (availability may vary).
Nov
18
answered Is the output of AES-CBC + MAC the same size as the input?
Nov
18
comment How many characters per block in an El Gamal ECC cryptosystem?
Nope, ASCII is 7 bit, not 8 bit. Removed some damaging remarks. Probably the idea is to point out that you should use a hybrid cryptosystem, but I don't think that letting students do some calculations while abusing the cipher is a good idea. There are more reasons to use hybrid cryptosystems, speed is only one and possibly the least interesting.
Nov
18
comment Bouncy jdk 1.51 Serpent KAT tests vs Nessie vectors
If we would just all keep to big endian with most significant bit at the left, counting from 0 to 7 for bits everything would become so much easier. Little endian is only interesting for Intel and then only for the machine word size. I don't think the performance benefits come even close to outweighing the stupidity of little endian. Lets reverse the bytes not the bits. Right.
Nov
18
comment Bouncy jdk 1.51 Serpent KAT tests vs Nessie vectors
@John I couldn't find any other test vectors either, but I guess it is solved now...