Massive implications for Maidsafe and cryptocurrencies in general


#1

https://skidpaste.org/i94aYFx0

TL;DR some claims that SSL and all other encryption has been rendered obsolete by backdoors they have discovered in certain components. If true this would have massive implications for Maidsafe but also for bitcoin as encryption is what prevents doublespending and basically gives value to the currency. Has anyone seen this yet? Thoughts?


#2

#####Moved to cybersecurity category

And this is where projects like SAFE can be a solution rather than being caught up in the problems in other encryption methods.

SAFE doesn’t have a backdoor, so it does not fall under the above analysis. It is opensource so its encryption methods can be examined and checked for any backdoors.


#3

Having read that article, it starts of as an infomercial with typical ranting and raving.

Then after 300 odd lines they say lets show it with some concrete examples

Then after running the openssl command 3 times without breaking anything they conclude with

EDIT: BTW padding is often required in encryption because they need to encrypt blocks of certain size and not all files have exactly the right number of bytes.

Perhaps the real question is “Was this a serious article???


#4

Honestly its been so long since I’ve looked at actual encryption code I just wanted some other eyes on this. I was hoping that is was a hoax/not real but couldn’t really tell myself…


#5

If it helps, we use sodium which is a cross platform version of Bernsteins NACL library. It has lots of eyes on it. Zcash use the same and we have discussed a joint audit of that codebase to further ensure no backdoors/bad bugs etc. It’s pretty good code though and can be audited. The parts we use are very small in themselves. There is also rust code available, but we do not use that yet as it’s not well enough reviewed and I have caution over llvm optimisations with regards to timing attacks (the c libs have constant time ops which help there, llvm (which can also compile c code) is not clear in that it wold not optimise away the constant time blocks for more efficiency, but in crypto that’s not always what’s required).
I would love to see llvm/rust code get a serious review as safety is also a massive consideration.


#6

Speaking of Heartbleed, what do you all think of this, would Rust have prevented Heartbleed?


#7

The ominous ‘warnings’ hidden in the comments by a mysterious ‘contractor’ turn out after a bit of googling to be a bona fida remark by the developers about the practical limits of randomness, at least that’s how I read it (original doc here). I can’t speak about the validity of the experiments, but the general tone and a number of red herrings (The Larry Hughes Jr. reference is another one) suggest this should be filed under ‘interesting but probably nonsense’.


#8

I read it all

I don’t think we need to worry, the guy never break anything

He is interpreting some “in code comments” as warning when they are not really

He is able to replicate encryption (with the password and every info necessary for that) : any one can do that as long as you have the algorithm, which you can have since it is opensource, I would even say : thank god you can replicate it.

Also the post is unreadable, looks like some kind of personal notes made with notepad from a teen that want to play special agents (or something like that)

I think the three number are some kind of timestamp, that’s why they are always different. (not the usual unix timestamp, too big for that)

clearly not


#9

Thanks for checking it!