On 2022/2/2 01:50, Bruce Momjian wrote:
> Well, I sent an email a week ago asking if people want to advance this
> feature forward, and so far you are the only person to reply, which I
> think means there isn't enough interest in this feature to advance it.
I am still focus on this thread.
and I
On 2021/11/29 18:05, Antonin Houska wrote:
> Does this test really pass regression tests? In BufFileRead(), I would
> understand if you did
>
> + file->pos = offsetInBlock;
> + file->curOffset -= offsetInBlock;
>
> rather than
>
> + fil
patch adjust file->curOffset and file->pos before the real IO to
ensure the start offset is aligned.From e04c2595711998d2c3eb4546e98a38d340200949 Mon Sep 17 00:00:00 2001
From: Sasasu
Date: Fri, 26 Nov 2021 00:12:14 +0800
Subject: [PATCH] buffile: ensure start offset is aligned with BLCKSZ.
On 2021/11/2 02:24, Stephen Frost wrote:
I can understand the general idea that we should be sure to engineer
this in a way that multiple methods can be used, as surely one day folks
will say that AES128 isn't acceptable any more.
Cheers!
OpenPGP_0x4E72AF09097DAE2E.asc
Description: OpenPGP pub
On 2021/10/26 17:33, Yura Sokolov wrote:
Yes, AES with AES-NI is fastest. But not so much.
And, AES-CTR could be easily used instead of ChaCha12 in Adiantum.
Adiantum uses ChaCha12 as a stream cipher, and any other stream cipher will
be ok as well with minor modifications to algorithm.
not so
On 2021/10/26 04:32, Yura Sokolov wrote:
And among others Adiantum looks best: it is fast even without hardware
acceleration,
No, AES is fast on modern high-end hardware.
on X86 AMD 3700X
type 1024 bytes 8192 bytes 16384 bytes
aes-128-ctr 8963982.50k 11124613.88k 11509149
On 2021/10/22 01:28, Stephen Frost wrote:
None of these are actually working with or changing the data though,
they're just copying it. I don't think we'd actually want these to
decrypt and reencrypt the data.
OK, but why ALTER TABLE SET TABLESPACE use smgrread() and smgrextend()
instead of c
On 2021/10/20 20:24, Stephen Frost wrote:
> PG does have a block-based IO API, it's just not exposed as hooks. In
> particular, take a look at md.c, though perhaps you'd be more interested
> in the higher level bufmgr.c routines. For the specific places where
> encryption may hook in, looking at
On 2021/10/20 02:54, Stephen Frost wrote:
> I agree with Robert- using hooks for this really isn't realistic.
OK, I agree use hooks is too invasive. Just a whim, never mind.
But If PG has a clear block-based IO API, TDE is much easier to
understand. security people may lack database knowledge b
On 2021/10/19 00:37, Robert Haas wrote:
I think what we ought to be doing at
this point is combining our efforts to try to get some things
committed which make future work in this area committed - like that
patch to preserve relfilenode and database OID, or maybe some patches
to drive all of our
On 2021/10/16 04:57, Tomas Vondra wrote:
>
> Seems reasonable, on the assumption the threat models are the same.
On 2021/10/16 03:22, Stephen Frost wrote:
plain64: the initial vector is the 64-bit little-endian version of the
sector number, padded with zeros if necessary
That is, the default fo
Just a mention. the HMAC (or AE/AD) can be disabled in AES-GCM. HMAC in
AES-GCM is an encrypt-then-hash MAC.
CRC-32 is not a crypto-safe hash (technically CRC-32 is not a hash
function). Cryptographers may unhappy with CRC-32.
I think CRC or SHA is not such important. If IV can be stored, I b
CBC.
many mails before this mail do a clear explanation, I just repeat. :>
On 2021/10/7 22:28, Robert Haas wrote:
> I'm a little concerned by the email from "Sasasu" saying that even in
> XTS reusing the IV is not cryptographically weak. I don't know enough
> about these d
在 2021/9/5 下午10:51, Sasasu 写道:
For AES-GCM, a predictable IV is fine. I think we can decrypt and
re-encrypt the user data in pg_upgrade. this will allows us to use
relfile oid + block number as nonce.
relfile oid + block number + some counter for heap table IV. I mean
Hi, community,
It looks like we are still considering AES-CBC, AES-XTS, and
AES-GCM(-SIV). I want to say something that we don't think about.
For AES-CBC, the IV should be not predictable. I think LSN or HASH(LSN,
block number or something) is predictable. There are many CVE related to
AES-C
15 matches
Mail list logo
