2
$\begingroup$

I know you shouldn't roll your own crypto and generally its not a good idea to implement (and then deploy) any extensively tested and recommended algorithms by yourself either.

I have already seen this question, and as far as I understand, the main problem with implementing things yourself is that you will probably remain vulnerable to a host of side-channel attacks.

But suppose I have already implemented AES (just for fun and as a learning experience). What if I now use that implementation for simply encrypting files locally (and then perhaps back them up on the cloud or on removable media)? Since nobody other than me would be using the implementation, most of the side channel attacks would not apply. For instance, since no attacker can request an encryption/decryption (the way it works with a server), no timing attack can be carried out. Would this be as secure as using an extensively tested implementation?

In other words would using my own implementation of AES provide security for data at rest equivalent to the security provided by extensively tested implementations or will using it still be a stupid idea?

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ This is an interesting question, but one that I think would be better answered on Crypto.SE. How does a crypto implementer reach a level of trust in their implementation of an algorithm? $\endgroup$
    – gowenfawr
    Commented Jun 29, 2020 at 18:14
  • $\begingroup$ @gowenfawr Well if the question I linked to belongs to Sec.SE, I guess mine should should too. Not sure though. $\endgroup$
    – user80567
    Commented Jun 29, 2020 at 18:16
  • $\begingroup$ Remember that security is not a binary proposition. "Is this sufficiently secure?" is an incomplete question, because that can only be answered for your individual use case. "Sufficiently secure" looks completely different for an anonymous cutest-cat-picture voting site than it does for the website used to launch nuclear attacks. If it's your own data you are securing then the question really boils down to, "Is it secure enough for you?". $\endgroup$
    – Conor Mancone
    Commented Jun 29, 2020 at 19:42
  • 1
    $\begingroup$ I guess it's sufficiently secure as long as you don't make serious mistakes (like producing encryption data with obvious patterns) and as long as you are not the target of an advanced attacker $\endgroup$
    – reed
    Commented Jun 29, 2020 at 20:02
  • $\begingroup$ Not really an answer but consider this: you mentioned that side channels would not apply since your are doing local operations, therefore no active adversary. But it could still be that you are under attack by an adversary! Imagine that you are encrypting emails with your own crypto, then uploading them to a cloud. However anyone can send you emails, including the cloud provider! So if you went as far as creating a custom mode of operation for AES(since it is not an encryption scheme on its own) you would be exposed to CPA attacks. $\endgroup$
    – Marc Ilunga
    Commented Jul 8, 2020 at 13:51

1 Answer 1

Reset to default
2
$\begingroup$

The big problem with RYO is the unknown unknowns. With popular implementations, there are fewer unknowns, more opportunities to find and fix flaws (more eyes on the code), and more guidance if something bad happens.

Think of it like an Ikea dresser; fine in the design studio, fine in the factory, fine in the store, deadly in a toddler's room. Without widespread dice-rolling, you might not find out about a flaw until it's too late and something bad happens to you alone. Also consider that the Maginot Line held as intended, yet still completely failed it's original purpose.

With a "real" AES, there's almost certainly targets juicer than your online backups to fall first, buying you time to fix vulnerabilities. There's no compelling reason stated that mitigates these risks or makes an important trade off, eg: lower battery usage than existing solutions. All i see is risk, no reward, and that makes it a no-brainer.

That said, if your implementation is interoperable with common tools, that suggests that your attack profile for at-rest data is likely similar to those common tools. That is, as long as you don't have mistakes or weaknesses, but that again is something of an unknown at this point; is the reward worth the risk?

Improve this answer
$\endgroup$
2
  • $\begingroup$ So you mean if my implementation matches the known answer tests and other implementations, it should provide as much security for data at rest as the other implementations, but its still a bad idea? $\endgroup$
    – user80567
    Commented Jun 30, 2020 at 9:20
  • $\begingroup$ @nobody Just because your implementation matches known tests doesn't mean it doesn't have terrible problems. For example, if you used GCM mode but you goofed up the IV randomization and used some duplicates, or you used ECB mode, or you used the encryption key for something else that allows it to be inferred, or ... any of a zillion other mistakes. $\endgroup$
    – Gordon Davisson
    Commented Jul 10, 2020 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.