Defensive Java Programming Notes (09 of 11) Poorly Implemented Cryptography

  • strict warning: Non-static method view::load() should not be called statically in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
Leeland's picture

Cryptography is effective only if it is used properly. It is way too easy to use very strong cryptography libraries very wrong. The most common problems with cryptography implementations are:

  • Use of home grown algorithms (lets face it unless you have a PhD in mathematics and another in cryptography you should not write a cryptographic algorithm for a production system.);

  • Cryptography depends on REALLY random seed data and the standard rand() calls are NOT random enough for strong enough cryptographic functions let alone strong cryptographic solutions;

  • Key management which is a major SOURCE of problems, this is the weakest link in almost ALL cryptographic solutions; and

  • Use of home grown "secure" communications protocols (same comments as for use of home grown algorithms.)




Frankly I am aware of no cryptographic solution which has been proven to be "hard." Which means they all have a possible vulnerability which will render them useless. Therefore it is better to use some kind of library tie in or driver style implementation so you can later swap in an alternate solution.



If you intend for something to stay secret for 100 years, you cannot expect to hide it forever. You need to know that within 10 years you will likely have to shift to a new algorithm or protocol. So plan for that eventuality.



You cannot hide anything with math forever.



Some guidelines for Java coding can be found at: Secure Coding Guidelines for the Java Programming Language, version 2.0 http://java.sun.com/security/seccodeguide.html



Mitigation

  • Don't use home ground crypto solutions

  • Never use rand() (instead use java.security.SecureRandom)

  • Never hard code keys

  • Avoid passing secrets around in memory

  • Use RSACryptoServiceProvider.ExportParameters(false) to make key generation easier and more robust

  • Avoid Key Management problems by using Data Protection API

If you cannot see the above picture it is attached below.

Here's an alternative way to generate random numbers: With a lava lamp! El_wombato writes - "A few years back the lava lamp random number guys (yes, they really did photograph lava lamps with a webcam) came up with a simpler technique. They sample the noise off a CCD chip in a webcam. The process is explained here" - http://www.lavarnd.org/what/process.html.



AttachmentSize
can-detail.jpg39.73 KB

Thread Slivers eBook at Amazon