Your company should hire a security expert to help with the project, and start fresh.
I know that not answering your immediate technical questions might seem frustrating, but I can promise you that no amount of technical detail that can be reasonably provided in a StackExchange answer is going to significantly benefit you, or your organisation, given the current trajectory of this project.
The project design process so far appears to be:
- Your organisation has identified a business requirement that is not currently met by existing capabilities, and you have decided to build a cloud-based CRM to fulfil that requirement.
- Your manager has decided that client-side encryption is a requirement, and delegated the responsibility for designing this to you (someone who is not a security specialist).
- You have investigated a number of technologies to implement the client-side encryption with.
While it's good that security is a priority, the organisation's current approach to the project has a number of issues.
First, and most critically, everyone is moving too far ahead, too quickly. You're already looking at software stacks to support the implementation details, but the security of a system like this is grounded in the architecture and design, not which database or web storage solution you use. A lack of planning in this area will almost always land you in a situation where the system cannot achieve its business goals and security requirements, and attempts to patch up the gaps will leave you with a ton of technical debt.
A custom cloud-based CRM has been chosen as a solution to a business problem. However, it isn't clear that sufficient security analysis went into this decision. Instead of "we need X => we can do that with Y => that could be secured with Z => how do we do Z?", your company should be asking "how do we achieve X in a secure manner?". It doesn't seem like there's a threat model, nor does it seem like any of the security decisions are being driven by that threat model.
You've realised that the task your boss has asked of you is beyond your current area of expertise, and you're looking for help. That's a good thing - you've identified a knowledge gap and you're looking to fill it. Unfortunately, when it comes to projects like this, getting help with individual technical details isn't going to be enough. These systems have a lot of hidden subtleties and pitfalls, and navigating those is as much about experience as it is deep technical knowledge. This type of project security support is a completely different job to developing software.
I'm also worried that your organisation has committed to this approach without first performing a feasibility study to identify whether you have the prerequisite knowledge and experience in-house. Building a secure multi-party document exchange solution around an untrusted server model is a complicated undertaking that requires deep knowledge of security and cryptography. Interactive features like planners and calendars are even more complicated. The smallest detail can hide a footgun that breaks the entire security model, sometimes in ways that can't be resolved without completely re-designing the system (which is obviously not feasible). I've worked on designs for these types of systems, and I've assessed many more, and I'd consider them to be one of the hardest types of system to get right.
To be clear: these criticisms are not intended to be negative or accusatory. I've worked with hundreds of organisations over my career, on thousands of projects, and it's far from uncommon to see this type of approach to a project. When you don't have someone to steer you in the right direction, all you can do is forge ahead, muddle your way through, and try to get things done. There's no shame in that. But the one constant throughout all of those engagements is that companies who get security experts to help guide them at the earliest possible stages - when they're just deciding that they might need to build a system - are the ones who don't end up with a pentest report full of critical severity issues at the end, and don't end up spending thousands on re-tests and additional security controls for a system that only half does what they wanted it to. From a purely fiscal perspective: spending money on security consultation at the start of a project saves you far more money in ongoing costs later.
I'm sympathetic to the position you're in. I've been a developer, and I certainly didn't get to make the big project decisions. If you take this answer to your boss and the project lead/stakeholders (hi!), I hope it steers them in the right direction and saves both you and the company some headaches along the way.