jy-p

4 ms·

1.
by jy-p 14y ago
maybe oracle would fix my javas if i paid them for a support contract. it's only USD 10 mln :P
2.
by jy-p 14y ago
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 out-of-band method to ch
3.
by jy-p 14y ago
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 ;)
4.
by jy-p 14y ago
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 password --> CBC-MAC --&
5.
by jy-p 14y ago
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 blazing a new trail i
6.
by jy-p 14y ago
it is essentially open sourced already - the client-side crypto is done in javascript which you can download or find online.
7.
by jy-p 14y ago
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 on the banks of CC com
8.
by jy-p 14y ago
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.
9.
by jy-p 14y ago
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 incorrect.