Al Mac wrote on 10/06/2007 23:53:18:
There is also access to the decryption algorithm, as used by
whatever software.
My understanding is that in the TJX breach, the data was encrypted, but
the
hackers got access to the decryption algorithm, rendering the encryption
protection worthless.
A cryptosystem that relies solely on the secrecy of the algorithm is
probably a bad cryptosystem. I would strongly recommend that people use a
well-known algorithm such as AES for their encryption needs.
I have witnessed security where characters are altered in-place.
For example, any given character in Hexadecimal is represented by two
standard characters like say E-7 and they in turn are represented by a
string of binary values. One algorighm flips bits such that any E is
replaced by an A, and other such combination replacements, so you end up
with a string of characters that are intelligible but scrambled. That
kind
of approach will not alter the number of characters that is the size of
the
field.
This is known as the 'Caesar cipher'. It can be cracked by really simple
cryptanalysis and at least as weak as no encryption at all.
I have also seen where some fields are labeled for a particular purpose,
but people have keyed into them some other content. So there coult be
data
content that needs to be protected, but you would not know it from the
field naming. There would need to be analysis of content according to
patterns that would indicate that what's in there is not consistent with
field labeling.
That's a really good point Al. I think that parsing a free-form comment
field for sensitive data would be extremely difficult. I good solution
might be to search for common identifiable info like bank account number,
credit card number, and any pertinent government ID numbers (health
insurance, drivers licence, social services, etc.), and warn the user. In
my mind, you either encrypt the field every time, or never encrypt it and
train people not to put in sensitive data in fields not designed for that
purpose.
I think someone else mentioned this earlier, but is worth repeating.
Choosing a crypto algorithm and implementing it is probably the easiest
part of this process. The really challenging bit comes from human factors
such as people 'repurposing' fields, who has access to sensitive data, key
management and so on.
Hope this helps,
Adam
Attention:
The information contained in this message and or attachments is
intended only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited. If you received this message in error, please contact the sender
and
delete the material from any system and destroy any copies. Thank you for your
time and consideration.
Attention:
Le contenu de ce message et(ou) les fichiers ci-joints s?adressent
exclusivement à la personne ou -entité à laquelle ils sont destinés. Ils
peuvent
contenir de l?information confidentielle, protégée et(ou) classifiée. Il est
strictement interdit à toute personne ou entité autre que le(la) destinataire
prévu(e) de ce message d?examiner, de réviser, de retransmettre ou de diffuser
cette information, de prendre une quelconque action en fonction ou sur la base
de celle-ci, ou d?en faire tout autre usage. Si vous avez reçu ce message par
erreur, veuillez communiquer avec l?expéditeur(trice), supprimer ce message et
les fichiers ci-inclus de tout système, et en détruire toutes copies, qu?elles
soient électroniques ou imprimées. Nous vous remercions de votre entière
collaboration.
midrange.com
