maybe oracle would fix my javas if i paid them for a support contract. it's only USD 10 mln :P
lol tedu :)
it is conceivable that such a system could work but it would have to rely on some kind of authenticity check on the binary/script that runs. when "crossing your t's and dotting your i's" it is usually best to use an…
well, he's talking about software, so getting into hardware exploits is a bit out-of-scope. that's not to say you shouldn't be worried either your silicon or NIC firmware are compromised ;)
i wasn't suggesting that they were comparable, rather that in mega's system a pbkdf makes more sense where they chose to use cbc-mac. without going back and looking at the mega js, i recall it working as follows…
if by "cut down tall poppies" you mean bring mega's claims of security and privacy in-line with reality, sure. there are plenty of people doing more interesting work with encrypted data storage. to suggest that mega is…
it is essentially open sourced already - the client-side crypto is done in javascript which you can download or find online.
if the crypto implementation is this poorly thought-out, you can only imagine how shaky the rest of the backend code is. it would not surprise me if the service is shutdown again somehow. i would guess they would lean…
agreed, doing aes-256-cbc with a MAC is not exactly the first thing that comes to mind when it's a clear case for using a pbkdf. you can probably drive a nail with a screwdriver handle if you try hard enough.
plenty of people have done this before, they just weren't nearly as focused on dodging legal liability for housing copyrighted data. to claim that nobody has done client-side encrypted storage with sharing is clearly…
maybe oracle would fix my javas if i paid them for a support contract. it's only USD 10 mln :P
lol tedu :)
it is conceivable that such a system could work but it would have to rely on some kind of authenticity check on the binary/script that runs. when "crossing your t's and dotting your i's" it is usually best to use an…
well, he's talking about software, so getting into hardware exploits is a bit out-of-scope. that's not to say you shouldn't be worried either your silicon or NIC firmware are compromised ;)
i wasn't suggesting that they were comparable, rather that in mega's system a pbkdf makes more sense where they chose to use cbc-mac. without going back and looking at the mega js, i recall it working as follows…
if by "cut down tall poppies" you mean bring mega's claims of security and privacy in-line with reality, sure. there are plenty of people doing more interesting work with encrypted data storage. to suggest that mega is…
it is essentially open sourced already - the client-side crypto is done in javascript which you can download or find online.
if the crypto implementation is this poorly thought-out, you can only imagine how shaky the rest of the backend code is. it would not surprise me if the service is shutdown again somehow. i would guess they would lean…
agreed, doing aes-256-cbc with a MAC is not exactly the first thing that comes to mind when it's a clear case for using a pbkdf. you can probably drive a nail with a screwdriver handle if you try hard enough.
plenty of people have done this before, they just weren't nearly as focused on dodging legal liability for housing copyrighted data. to claim that nobody has done client-side encrypted storage with sharing is clearly…