Hi Vlad
Your remark is very interesting. You want to say that it's better to run SQL
queries on unpersonalized data, and then retrieve the encrypted data for those
records.
OK, I take this recommendation into account and I will forward it to my
company's projects.
Nevertheless, you say that it
*Hi All,*
*archive_mode *is turned *on *unfortunately in my Postgres 9.2 database.
Due to that disk space is full 100%. We are facing below problem when we
try to start the database.
*PANIC: could not read from control file:Success*
Please help me how to handle this situation.
*Log files con
Hi Didier,
I’m sorry to tell you that you are probably doing something (ie
handling/storing credit cards) which would mean you have to comply with PCI DSS
requirements.
As such you should probably have a QSA (auditor) who you can run any proposed
solution by (so you know they will be comfortab
Hi,
On 10/07/2018 08:32 PM, ROS Didier wrote:
> Hi Francisco
>
> Thank you for your remark.
> You're right, but it's the only procedure I found to make search on
> encrypted fields with good response times (using index) !
>
Unfortunately, that kinda invalidates the whole purpose of in-da
Additionally it is not clear why you want to search in table on encrypted
data. Usually you match user with it's unpersonalized data (such as login,
user ID) and then decrypt personalized data. If you need to store user
identifying data encrypted as well (e.g. bank account number) you can use a
det
Hello Didier,
Your email is didier@edf.fr. Are you working at Electricite de France,
and storing actual customers' credit card details? How many millions of
them?
Note that this mailing list is public; people looking for targets with poor
security from which they can harvest credit card nu
Didier,
you was given a few things to check in another my message on the same day.
You have not provided any feedback.
It is up to you how to implement your system, but you can with no doubt
consider your database as not encrypted with your approach. You (or
probably your management) have no under
You can consider outside DB encryption which is less of worry for performance
and data at rest will be encrypted.
Regards,
Virendra
-Original Message-
From: ROS Didier [mailto:didier@edf.fr]
Sent: Sunday, October 07, 2018 2:33 PM
To: fola...@peoplecall.com
Cc: pavel.steh...@gmail.com;
Hi Francisco
Thank you for your remark.
You're right, but it's the only procedure I found to make search on
encrypted fields with good response times (using index) !
Regarding access to the file system, our servers are in protected
network areas. few people can connect
ROS:
On Sun, Oct 7, 2018 at 3:13 PM, ROS Didier wrote:
> -INSERT INTO cartedecredit(username,cc) SELECT 'individu ' || x.id,
> pgp_sym_encrypt('test value ' || x.id, 'motdepasse','compress-algo=2,
> cipher-algo=aes256') FROM generate_series(1,10) AS x(id);
> -CREATE IN
Hi Paul
Thanks for the explanation. I think you are right.
I understand why the WHERE clause “cc=pgp_sym_encrypt('test
value 32', 'motdepasse');” does not bring anything back.
Best Regards
Didier ROS
De : p...@paulmcgarry.com [mailto:p...@paulmcgarry.com]
Envoyé :
Hi Pavel
Thanks you for your answer. here is a procedure that works :
-CREATE TABLE cartedecredit(card_id SERIAL PRIMARY KEY, username
VARCHAR(100), cc bytea);
-INSERT INTO cartedecredit(username,cc) SELECT 'individu ' || x.id,
pgp_sym_encrypt('test value ' || x
Hi Andrew,
Thanks for your great reply.
Andrew Gierth wrote:
"Phil" == Phil Endecott writes:
Phil> As a hack I tried ALTER FUNCTION to make it immutable,
A better approach is to wrap it in a function of your own which is
declared immutable, rather than hacking the catalogs:
create function
13 matches
Mail list logo
