<div><br></div>Also, there is this:<div><br></div><div><a href="http://xkcd.com/538/">http://xkcd.com/538/</a></div><div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>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. <br>
<br>
<br><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 1:52 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Oct 31, 2011 at 4:45 AM, Jon Watte <<a href="mailto:jwatte@gmail.com">jwatte@gmail.com</a>> wrote:<br>
> Crypto is actually quite hard, and building something "perfectly secure" is<br>
> even harder (some say impossible).<br>
<br>
</div>I agree<br>
<div class="im"><br>
> For passwords, it's often the case that you want to store the password<br>
> salted and one-way encrypted using something like bcrypt() to avoid brute<br>
> force attacks.<br>
> For credit card information, medical information, and similar, the technical<br>
> requirements may be significantly harder -- it may very well include<br>
> dedicated hardware that can be called upon to encrypt/decrypt data, but does<br>
> not leak the key separately.<br>
> A good book to get an understanding of many nuances is "Applied<br>
> Cryptography" by<br>
> Schneier. <a href="http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099" target="_blank">http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099</a><br>
> If you actually want to implement crypto in your own system, you can do a<br>
> *lot* worse than reading that book!<br>
<br>
</div>Yup - but this is just about algorithms which is only 10% of the story<br>
- rest is about<br>
deciding what attacks to protect against. (I have *never* seen a book<br>
that discusses this<br>
are they any?)<br>
<br>
You have to think about *exactly* how an attack will take place, then<br>
make sure it can't happen<br>
this is *very* difficult.<br>
<br>
If you dig up the standard for "Secure Electronic Transactions" you'll<br>
see what I mean.<br>
<br>
Crytography is the bit that is "well-understood" - attacks might<br>
involve peeping at the memory of your program<br>
while it is executing - does your program use virtual memory when this<br>
swaps to disk is the swap area on disk<br>
encrypted? - could somebody install a password sniffer in the firmware<br>
of your keyboard?<br>
<br>
Virtually all attacks on secure data are through side-channels, ie the<br>
crypto-algorithms are not broken<br>
they are bypassed by a smart (or even not so smart) trick - (Last<br>
month I was phoned up twice, by a guy<br>
who said my windows machine was hacked, and who wanted to to "help" me<br>
by getting me to download a<br>
program to fix this)<br>
<br>
You need to think about what kind of data protection you need and what<br>
kind of attack you are protecting against<br>
without a clear idea of the attack you are sunk. Example your disk<br>
contains encrypted passwords, but somewhere<br>
on the disk is a plain text copy of the password - in an unencrypted<br>
swap file, or in .bash_history or somewhere<br>
you never thought of ...<br>
<br>
Then having decided on the attack you have to decide "how difficult do<br>
I want to make life for the attacker?"<br>
<br>
Some cryptosystems will take (theoretically) a long time to break<br>
(until the theory is shown to be wrong :-)<br>
others are pretty simple.<br>
<div class="im"><br>
> (And, yes, crypto requires overall systems approaches; dropping an algorithm<br>
> in some low-level code is not sufficient for most kinds of attacks you want<br>
> to defend against)<br>
<br>
</div>very true<br>
<font color="#888888"><br>
/Joe<br>
</font><div><div></div><div class="h5"><br>
> Sincerely,<br>
> jw<br>
> --<br>
> Americans might object: there is no way we would sacrifice our living<br>
> standards for the benefit of people in the rest of the world. Nevertheless,<br>
> whether we get there willingly or not, we shall soon have lower consumption<br>
> rates, because our present rates are unsustainable.<br>
><br>
><br>
><br>
> On Sun, Oct 30, 2011 at 9:58 AM, Kristen Eisenberg<br>
> <<a href="mailto:kristen.eisenberg@yahoo.com">kristen.eisenberg@yahoo.com</a>> wrote:<br>
>><br>
>> This is a bit more of a general question than Erlang specific but I hope<br>
>> someone here can answer this, or simply point me to a place where it has<br>
>> already been answered.<br>
>> I'm writing a server in which I will be storing encrypted user data<br>
>> (unlike Sony). My problem is probably a product of zero experience with<br>
>> encryption combined with a lack of sleep, but I can't figure out how to do<br>
>> this securely. By that I mean I understand how to use crypto to<br>
>> encrypt/decrypt a piece of data but the Key and the Ivec have to be the same<br>
>> for both the encryption and decryption otherwise it doesn't work...so how do<br>
>> I make this happen without storing those two things "out in the open?" It<br>
>> seems like that can't be the optimal solution since anyone who could just<br>
>> grab those and decrypt the data. Am I missing something completely obvious?<br>
>> Chris Hicks.<br>
>> Kristen Eisenberg<br>
>> Billige Flüge<br>
>> Marketing GmbH<br>
>> Emanuelstr. 3,<br>
>> 10317 Berlin<br>
>> Deutschland<br>
>> Telefon: +49 (33)<br>
>> 5310967<br>
>> Email:<br>
>> utebachmeier at<br>
>> <a href="http://gmail.com" target="_blank">gmail.com</a><br>
>> Site:<br>
>> <a href="http://flug.airego.de" target="_blank">http://flug.airego.de</a> - Billige Flüge vergleichen<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>