Abraham Elmahrek
Abraham Elmahrek
Thanks for submitting this bug @AboShanab . I think you're referring to this screen:  Note that the active...
Would be useful for key retention schedules and getting started with the library. See https://github.com/generalpiston/typeorm-encrypted/issues/36 for more info.
Take a peek at this test case: https://github.com/generalpiston/typeorm-encrypted/blob/master/test/find-operator.test.ts#L41
@Amraneze So, the way it works is it encrypts the field and checks it against the internal value. If the secrets / keys have changed, then it won't work. Unfortunately,...
@Amraneze hey that's a great point. Perhaps the IV should be different for each record?
@Amraneze I don't think we need a test project. Every thing you said tracks. I'm going to think about the security implications of using the same IV a bit and...
@Amraneze @razr22 having a different IV is interesting since it would reduce the cardinality of sets open to attack. I think to do this, we'd have to do one of...
@coderdan thanks for the insight. Are you recommending we use randomly generated IVs?
@coderdan I guess with GCM mode, the nonce can't repeat. In CBC mode, a repeat isn't catastrophic, but it's slower. We should probably allow the `iv` function to be an...
Hmm... interesting use case... default values are usually set in the schema. The current implementation doesn't do any encryption in DDLs. If it did, then every time the key changes,...