Merge pull request #201 from geeksville/dev

Fix crypto doc links

docs/faq.md

@@ -4,7 +4,7 @@ This project is still pretty young but moving at a pretty good pace. Not all fea
 Most of these problems should be solved by the beta release (within three months):
 
 - We don't make these devices and they haven't been tested by UL or the FCC. If you use them you are experimenting and we can't promise they won't burn your house down ;-)
-- The encryption [implementation](software/crypto.md) has not been reviewed by an expert. (Are you an expert? Please help us)
+- The encryption implementation is good but see this list of [caveats](software/crypto.md#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
 - A number of (straightforward) software work items have to be completed before battery life matches our measurements, currently battery life is about three days. Join us on chat if you want the spreadsheet of power measurements/calculations.
 - The Android API needs to be documented better
 - No one has written an iOS app yet. But some good souls [are talking about it](https://github.com/meshtastic/Meshtastic-esp32/issues/14) ;-)

docs/software/crypto.md

@@ -10,7 +10,7 @@ the project developers are not cryptography experts. Therefore we ask two things
 
 ## Summary of strengths/weaknesses of our current implementation
 
-Based on comments from reviewers (see below), here's some tips for usage of these radios you know the level of protection offered:
+Based on comments from reviewers (see below), here's some tips for usage of these radios.  So you can know the level of protection offered:
 
 * It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
 * Warning: If an attacker is able to get one of the radios in their position, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
@@ -36,10 +36,6 @@ If you are reviewing our implementation, this is a brief statement of our method
 - Each 16 byte BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
 - The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Since our packets are small counter portion will really never be higher than 32 (five bits).
 
-### Remaining todo
-
-- Have the app change the crypto key when the user generates a new channel
-
 ## Comments from reviewer #1
 
 This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):