-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
98 lines (71 loc) · 10.5 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[RNCryptor]]></title>
<link href="http://RNCryptor.github.io/atom.xml" rel="self"/>
<link href="http://RNCryptor.github.io/"/>
<updated>2014-01-23T14:48:08-05:00</updated>
<id>http://RNCryptor.github.io/</id>
<author>
<name><![CDATA[Rob Napier]]></name>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[New Implementations: C++ and C#]]></title>
<link href="http://RNCryptor.github.io/blog/2014/01/23/new-implementations-c-plus-plus-and-c-number/"/>
<updated>2014-01-23T14:34:46-05:00</updated>
<id>http://RNCryptor.github.io/blog/2014/01/23/new-implementations-c-plus-plus-and-c-number</id>
<content type="html"><![CDATA[<p>Thanks to <a href="https://github.com/curtisdf">Curtis Farnham</a>, we now have basic implementations of RNCryptor in <a href="https://github.com/RNCryptor/RNCryptor-cpp">C++</a> and <a href="https://github.com/RNCryptor/RNCryptor-cs">C#</a>.</p>
<p>Neither Curtis nor I claim to be expert in C++ or C#. The C# implementation was developed in Mono, not .NET. If you’re a C++ or C# developer, we would love input and pull requests to improve these implementations.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Draft v3.1 and v4.0 Specs for Comment]]></title>
<link href="http://RNCryptor.github.io/blog/2014/01/21/draft-v3-dot-1-and-v4-dot-0-specs-for-comment/"/>
<updated>2014-01-21T20:52:22-05:00</updated>
<id>http://RNCryptor.github.io/blog/2014/01/21/draft-v3-dot-1-and-v4-dot-0-specs-for-comment</id>
<content type="html"><![CDATA[<p>I’ve published draft specs for the next two versions of the RNCryptor format. I split it into two versions because the v3.1 changes are backward compatible while the v4.0 changes are not. Updating the ObjC implementation to v4.0 may take a little while, because I plan to also update the API at the same time. I can probably get a new version that handles v3.1 pretty quickly.</p>
<p>Comments on these drafts are highly encouraged.</p>
<!-- more -->
<p><a href="https://github.com/RNCryptor/RNCryptor-Spec/blob/master/draft-RNCryptor-Spec-v3.1.md">v3.1</a> allows you to configure PBKDF2 rounds in orders of magnitude from 10<sup>1</sup> (10) through 10<sup>7</sup> (1,000,000). This should address the many ad hoc implementations that people have used to support JavaScript. It will also allow me to finish <a href="https://github.com/RNCryptor/rncryptor-js">rncryptor-js</a>, which could not be implemented in a compatible way without support in the format for lower iteration counts. v3.1 is completely backward compatible with v3.0.</p>
<p><a href="https://github.com/RNCryptor/RNCryptor-Spec/blob/master/draft-RNCryptor-Spec-v4.0.md">v4.0</a> is a more radical change to the format. Rather than randomly generating the IV, encryption key, and HMAC key, it derives these from a single master key and a random salt using a KDF. For key-based encryption, this is <a href="https://tools.ietf.org/html/rfc5869">HKDF</a>. For password-based encryption, this is PBKDF2 and HKDF. It also adds a validator that can be used to quickly verify that the key/password is correct before processing the entire file (this also differentiates between incorrect password and most corruption errors; previously the caller could not differentiate these error conditions).</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Why Not Scrypt?]]></title>
<link href="http://RNCryptor.github.io/blog/2014/01/21/why-not-scrypt/"/>
<updated>2014-01-21T08:37:30-05:00</updated>
<id>http://RNCryptor.github.io/blog/2014/01/21/why-not-scrypt</id>
<content type="html"><![CDATA[<p><a href="https://github.com/nguyenthanhhai">“NeXT Steve”</a> asks a very good question in RNCryptor <a href="https://github.com/RNCryptor/RNCryptor/issues/110">Issue #110</a>:</p>
<blockquote><p>Could you implement Scrypt for this function ?</p></blockquote>
<p>No.</p>
<p>This isn’t a comment on the security of <a href="https://www.tarsnap.com/scrypt.html">scrypt</a>. It isn’t a comment on its developer, Colin Percival, who was a <a href="http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html">major influence in my developing RNCryptor</a>. I like scrypt. I hope it becomes popular. I have a great deal of respect for Colin.</p>
<!-- more -->
<p>RNCryptor will not support scrypt (or bcrypt) for the likely future because it’s not generally available in cryptographic toolkits. In particular, it’s not available in any of the toolkits that the current RNCryptor implementations rely on: <a href="http://www.opensource.apple.com/source/CommonCrypto/">Common Crypto</a>, <a href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SecretKeyFactory">SecretKeyFactory</a>, <a href="http://pythonhosted.org/pycrypto/Crypto.Protocol.KDF-module.html">Crypto.Protocol.KDF</a>, <a href="https://github.com/bitwiseshiftleft/sjcl">SJCL</a>, and <a href="http://ruby-doc.org/stdlib-2.0/libdoc/openssl/rdoc/OpenSSL.html">OpenSSL</a>. I hope to provide implementations in more languages soon.<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> I expect almost all of them to have SHA-2, HMAC, AES-CBC, and PBKDF2 readily available, and I expect few of them will have scrypt or bcrypt in their most popular or built-in crypto libraries.</p>
<p>A primary goal of the RNCryptor format is to be easy to use and easy to implement on a wide variety of platforms. Its entire point is to make “doing AES correctly” the same as “doing AES easily.” It avoids creating any more dependencies than necessary, and it strongly avoids requiring implementers to write cryptographic primitives. It avoids adding options that make implementations more complicated.<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup> My ideal is that a basic implementation of RNCryptor should be possible in a couple hundred lines of code. The <a href="https://github.com/RNCryptor/ruby_rncryptor/blob/5fff939759d04c6e6c73f2cb35fec59e50445912/lib/ruby_rncryptor.rb">current Ruby implementation</a> is 80 lines including comments, and includes almost no math. That’s what I want it to look like.</p>
<p>This goal means I pick from readily available primitives to build a secure implementation. If I had my pick of primitives, I would almost certainly use an authenticated mode like CCM rather than CBC.<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup> But there are no authenticated modes that are commonly available. So RNCryptor uses AES-CBC+HMAC.</p>
<p><a href="http://crypto.stackexchange.com/users/28/thomas-pornin">Thomas Pornin</a>, probably my favorite contributor to crypto.stackexchange.com, <a href="http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415">sums it up well</a> discussing bcrypt:</p>
<blockquote><p>NIST has issued <a href="http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf">Special Publication SP 800-132</a> on the subject of storing hashed passwords. Basically they recommend PBKDF2. This does not mean that they deem bcrypt insecure; they say nothing at all about bcrypt. It just means that NIST deems PBKDF2 “secure enough” (and it certainly is much better than a simple hash !)….</p>
<p>While I recommend bcrypt, I still follow NIST in that if you implement PBKDF2 and use it properly (with a “high” iteration count), then it is quite probable that password storage is no longer the worst of your security issues.While I recommend bcrypt, I still follow NIST in that if you implement PBKDF2 and use it properly (with a “high” iteration count), then it is quite probable that password storage is no longer the worst of your security issues.</p></blockquote>
<p>PBKDF2 is sufficiently secure, and it’s the most commonly available KDF. So it’s what RNCryptor is going to rely on for the foreseeable future.</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>On the short-term radar: C#, C++, Scala (also Akka), Haskell. Others of medium-term interest: VB, Lua, Go, D. As always, please contact me if there’s a language you’re interested in helping with. RNCryptor is designed to be easy to implement and I can walk you through it.<a href="#fnref:1" rev="footnote">↩</a></p></li>
<li id="fn:2">
<p>Currently there is just one option: use a password or a raw key. I often debate whether it’s worth having that option (and several implementations do not support raw keys). In the next release of the spec, I plan to add a second option, number of PBKDF2 rounds, because it has been of such high demand and is absolutely necessary to implement RNCryptor in JavaScript. <a href="#fnref:2" rev="footnote">↩</a></p></li>
<li id="fn:3">
<p>I know Colin Percival’s <a href="http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html">arguments for preferring encrypt-than-mac</a> rather than authenticated encryption (AE). While I understand where he’s going with the argument, I believe it’s much easier for downstream developers to use AE correctly. This is why I’ve also come to disagree with his stance on CTR, even though that’s what I used in the original version of RNCryptor. It’s just too easy to do CTR wrong, and then it’s totally insecure. If you mess up CBC a little bit, it doesn’t completely fall apart. CBC also happens to be the most commonly available mode, so it’s the strong favorite for RNCryptor anyway.<a href="#fnref:3" rev="footnote">↩</a></p></li>
</ol>
</div>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[New RNCryptor Site]]></title>
<link href="http://RNCryptor.github.io/blog/2014/01/14/new-rncryptor-site/"/>
<updated>2014-01-14T15:28:53-05:00</updated>
<id>http://RNCryptor.github.io/blog/2014/01/14/new-rncryptor-site</id>
<content type="html"><![CDATA[<p>RNCryptor has a new home of sorts. It now lives it its own organization, and I’ve split all the implementations into their own repositories. There’s a new <a href="https://github.com/RNCryptor/RNCryptor-Spec">RNCryptor-Spec</a> repository to track the specification itself. And there’s this nice, new website to make things a little easier to find. I hope it helps you find what you need. I expect a lot of work on RNCryptor in 2014.</p>
]]></content>
</entry>
</feed>