Am Do., 19. Mai 2022 um 15:54 Uhr schrieb Robert Newson :
>
> Hi,
>
> My proposal is not about backups, encrypted or otherwise, though I can see
> there's a relationship. Could the built-in encryption of my proposal also be
> suitable for protecting a backup of these files? Yes, I think so.
Hi,
My proposal is not about backups, encrypted or otherwise, though I can see
there's a relationship. Could the built-in encryption of my proposal also be
suitable for protecting a backup of these files? Yes, I think so. Given key
rotation we would expect to eventually have backups that need
On Wed, 18 May 2022, 19:31 Robert Newson, wrote:
> Hi Will,
>
> I still don't see how public/private encryption helps. It seems the
> private keys in your idea(s) are needed in all the same places and for the
> same duration as the secret keys in mine. I think it's clear, though, that
> I didn't
proposal's use of key wrapping techniques came
without an explanation, which I include later in this post.
The core part of 'native encryption' is in the first commit, the mere mechanics
of using AES in counter mode at the right places in couch_file to cause all the
bytes on disk to be correctly
Hi Robert,
I think it is best to try to clear up the matter of non-extractable
keys since that is where I am confused about the capabilities without
asymmetric keys. The setup I am used to seeing for non-extractable
keys looks similar to crypto's OpenSSL engine references where erlang
says it
en some time to think over your PR and writeup, and have the
> following comments:
>
> benefits of the PR
> I like this idea of native encryption a lot. While lower layers can
> offer encryption, I think there are a lot more situations where the
> lower layer has been delega
Hi Robert,
I've taken some time to think over your PR and writeup, and have the
following comments:
benefits of the PR
I like this idea of native encryption a lot. While lower layers can
offer encryption, I think there are a lot more situations where the
lower layer has been delegated
he encryption header at the start of each file. More care
is needed there, of course.
To the commits themselves;
* demonstrate native encryption
This introduces only the essential changes for native encryption. A single
"master" key is used. We use the NIST AES Key Wrap algorithm (copi
Hi,
Good feedback, thanks all.
B.
> On 15 Mar 2020, at 13:25, Dave Cottlehuber wrote:
>
> On Thu, 12 Mar 2020, at 17:35, Robert Samuel Newson wrote:
>> Hi,
>>
>> Yes, platform independent, it's not custom C work, just calls into the
>> existing crypto module.
>>
>> Invisible at the API
On Thu, 12 Mar 2020, at 17:35, Robert Samuel Newson wrote:
> Hi,
>
> Yes, platform independent, it's not custom C work, just calls into the
> existing crypto module.
>
> Invisible at the API layer, it's all about the protection of data at
> rest within FDB.
Hey Bob,
Quietly excited about
oesn't
> involve the user.
>
> B.
>
>> On 12 Mar 2020, at 17:17, Joan Touzet wrote:
>>
>>
>>
>> On 2020-03-12 12:29, Robert Samuel Newson wrote:
>>> Hi All,
>>> Our team at IBM are working on native encryption of document content for
to access any part of it and this doesn't involve the
user.
B.
> On 12 Mar 2020, at 17:17, Joan Touzet wrote:
>
>
>
> On 2020-03-12 12:29, Robert Samuel Newson wrote:
>> Hi All,
>> Our team at IBM are working on native encryption of document content f
On 2020-03-12 12:29, Robert Samuel Newson wrote:
Hi All,
Our team at IBM are working on native encryption of document content for the
Cloudant service and are wondering if there'd be interest (or objection!) to
this landing as a CouchDB feature?
Yes!
This is only targeted
Hi All,
Our team at IBM are working on native encryption of document content for the
Cloudant service and are wondering if there'd be interest (or objection!) to
this landing as a CouchDB feature?
This is only targeted at the (future) CouchDB 4.0 release which introduces
FoundationDB
14 matches
Mail list logo
