[erlang-questions] Encrypting/Decrypting data

[Robert Virding]

Xkcd rules. 

----- Original Message -----

> Also, there is this:

> http://xkcd.com/538/

> Sincerely,

> jw

> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world.
> Nevertheless, whether we get there willingly or not, we shall soon
> have lower consumption rates, because our present rates are
> unsustainable.

> On Mon, Oct 31, 2011 at 1:52 AM, Joe Armstrong < erlang@REDACTED >
> wrote:

> > On Mon, Oct 31, 2011 at 4:45 AM, Jon Watte < jwatte@REDACTED >
> > wrote:
> 
> > > Crypto is actually quite hard, and building something "perfectly
> > > secure" is
> 
> > > even harder (some say impossible).
> 

> > I agree
> 

> > > For passwords, it's often the case that you want to store the
> > > password
> 
> > > salted and one-way encrypted using something like bcrypt() to
> > > avoid
> > > brute
> 
> > > force attacks.
> 
> > > For credit card information, medical information, and similar,
> > > the
> > > technical
> 
> > > requirements may be significantly harder -- it may very well
> > > include
> 
> > > dedicated hardware that can be called upon to encrypt/decrypt
> > > data,
> > > but does
> 
> > > not leak the key separately.
> 
> > > A good book to get an understanding of many nuances is "Applied
> 
> > > Cryptography" by
> 
> > > Schneier.
> > > http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099
> 
> > > If you actually want to implement crypto in your own system, you
> > > can do a
> 
> > > *lot* worse than reading that book!
> 

> > Yup - but this is just about algorithms which is only 10% of the
> > story
> 
> > - rest is about
> 
> > deciding what attacks to protect against. (I have *never* seen a
> > book
> 
> > that discusses this
> 
> > are they any?)
> 

> > You have to think about *exactly* how an attack will take place,
> > then
> 
> > make sure it can't happen
> 
> > this is *very* difficult.
> 

> > If you dig up the standard for "Secure Electronic Transactions"
> > you'll
> 
> > see what I mean.
> 

> > Crytography is the bit that is "well-understood" - attacks might
> 
> > involve peeping at the memory of your program
> 
> > while it is executing - does your program use virtual memory when
> > this
> 
> > swaps to disk is the swap area on disk
> 
> > encrypted? - could somebody install a password sniffer in the
> > firmware
> 
> > of your keyboard?
> 

> > Virtually all attacks on secure data are through side-channels, ie
> > the
> 
> > crypto-algorithms are not broken
> 
> > they are bypassed by a smart (or even not so smart) trick - (Last
> 
> > month I was phoned up twice, by a guy
> 
> > who said my windows machine was hacked, and who wanted to to "help"
> > me
> 
> > by getting me to download a
> 
> > program to fix this)
> 

> > You need to think about what kind of data protection you need and
> > what
> 
> > kind of attack you are protecting against
> 
> > without a clear idea of the attack you are sunk. Example your disk
> 
> > contains encrypted passwords, but somewhere
> 
> > on the disk is a plain text copy of the password - in an
> > unencrypted
> 
> > swap file, or in .bash_history or somewhere
> 
> > you never thought of ...
> 

> > Then having decided on the attack you have to decide "how difficult
> > do
> 
> > I want to make life for the attacker?"
> 

> > Some cryptosystems will take (theoretically) a long time to break
> 
> > (until the theory is shown to be wrong :-)
> 
> > others are pretty simple.
> 

> > > (And, yes, crypto requires overall systems approaches; dropping
> > > an
> > > algorithm
> 
> > > in some low-level code is not sufficient for most kinds of
> > > attacks
> > > you want
> 
> > > to defend against)
> 

> > very true
> 

> > /Joe
> 

> > > Sincerely,
> 
> > > jw
> 
> > > --
> 
> > > Americans might object: there is no way we would sacrifice our
> > > living
> 
> > > standards for the benefit of people in the rest of the world.
> > > Nevertheless,
> 
> > > whether we get there willingly or not, we shall soon have lower
> > > consumption
> 
> > > rates, because our present rates are unsustainable.
> 
> > >
> 
> > >
> 
> > >
> 
> > > On Sun, Oct 30, 2011 at 9:58 AM, Kristen Eisenberg
> 
> > > < kristen.eisenberg@REDACTED > wrote:
> 
> > >>
> 
> > >> This is a bit more of a general question than Erlang specific
> > >> but
> > >> I hope
> 
> > >> someone here can answer this, or simply point me to a place
> > >> where
> > >> it has
> 
> > >> already been answered.
> 
> > >> I'm writing a server in which I will be storing encrypted user
> > >> data
> 
> > >> (unlike Sony). My problem is probably a product of zero
> > >> experience
> > >> with
> 
> > >> encryption combined with a lack of sleep, but I can't figure out
> > >> how to do
> 
> > >> this securely. By that I mean I understand how to use crypto to
> 
> > >> encrypt/decrypt a piece of data but the Key and the Ivec have to
> > >> be the same
> 
> > >> for both the encryption and decryption otherwise it doesn't
> > >> work...so how do
> 
> > >> I make this happen without storing those two things "out in the
> > >> open?" It
> 
> > >> seems like that can't be the optimal solution since anyone who
> > >> could just
> 
> > >> grab those and decrypt the data. Am I missing something
> > >> completely
> > >> obvious?
> 
> > >> Chris Hicks.
> 
> > >> Kristen Eisenberg
> 
> > >> Billige Flüge
> 
> > >> Marketing GmbH
> 
> > >> Emanuelstr. 3,
> 
> > >> 10317 Berlin
> 
> > >> Deutschland
> 
> > >> Telefon: +49 (33)
> 
> > >> 5310967
> 
> > >> Email:
> 
> > >> utebachmeier at
> 
> > >> gmail.com
> 
> > >> Site:
> 
> > >> http://flug.airego.de - Billige Flüge vergleichen
> 
> > >> _______________________________________________
> 
> > >> erlang-questions mailing list
> 
> > >> erlang-questions@REDACTED
> 
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> 
> > >>
> 
> > >
> 
> > >
> 
> > > _______________________________________________
> 
> > > erlang-questions mailing list
> 
> > > erlang-questions@REDACTED
> 
> > > http://erlang.org/mailman/listinfo/erlang-questions
> 
> > >
> 
> > >
> 

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111031/e21254e8/attachment.htm>