Interesting Lee did work for us and is also a member of this forum, I must check his posts at some time to find these issues he mentions warning us about or at least get a sniff of such in between the lines of posts or something.
Basically much of this is FUD and surprising really as a contract Engineer that was not working in or seemed to have knowledge of the areas he seems now to “understand”. Lots of time spent here though which would be nice if it were focused on issues that would help. The assertion that the network relies on the difficulty of creating a key though is not correct and therefore is further surprising. We have certainly not seen any pull requests for any of this, so I suspect helping and assistance is not the purpose here.
I won’t go into some previous employee issues and why they are previous and not current, that is a different matter. A lack of understanding would not help though. Hopefully we can have many reviews etc. but in the open and copied to us so we can make use of them will help us all.
As part of innovation and creation of new devices like SAFE though we must take info from anywhere, but also realise there will be masses of inaccurate information where folk do seem to have inordinate time to criticise and there will be many reasons for such criticism, many of which we will never know, although we may guess. If they end up being a mechanism to distract though then it becomes dangerous. Chris Foster posted a really excellent article about being careful with certain “posts” it’s always worth noting that.
If there was an Engineer working in the code who had concerns they would be documented and we could react to them as we go along. That would be normal for sure. We do not simply though rely on key creation difficulty or group signing keys (which do not exist but were mentioned by me as an interesting thing to look at) etc. so we need to filer this info in the email and see if there is anything we can use and if there is then we would for sure 
As we pass through Alpha we are providing the functionality, as this is rolled out we are spending a ton of time on security, which is implemented bit by bit, for instance currently routing meetings are very focused on security, but in phases. So data republish, group security and hop security are all part of that. Network joining is also another part of this, so you create keys and get relocated based on that, but even this relocation does allow a targeting right now, but not by creating a key to do so, but in terms of continually joining and seeing where you got located to, then do this many of times with different nodes to get close. This is prevented though using many methods, such as forced relocation with breadcrumbs, relocation with safecoin and many others. We have not selected the relocation mechanism yet as it’s not time. right now differing sized capabilities are the issue to fix and we are on that. That is a much more difficult issue and probably should have been something way up in a critique of somebody wished to be damaging, as we can prove that. There is also secure_serialisation crate we created which is not fully used either, this introduces encrypted comms in crust but still requires incrementing counter for replay prevention. We have a few parts like this otherwise we would be launched already 
So if there is any useful info we will use it, as you would expect. 