Re: [Firebird-devel] Crypto Performance

I don't know of any known problems with AES/CBC. It is simply the most trusted crypto algorithm in the history of computing. It isn't possible prove that something can't be broken, but many, many very smart people have spent many years searching for an attack over 15+ years without success.

Re: [Firebird-devel] Crypto Performance

Jim, > I don't know of any known problems with AES/CBC. It is simply the most > trusted crypto algorithm in the history of computing. It isn't possible prove > that something can't be broken, but many, many very smart people have > spent many years searching for an attack over 15+ years without

Re: [Firebird-devel] Crypto Performance

Do you know AES-NI also support AES/GCM (Gaulois Counter Mode)? I have read several articles that advise to use AES/GCM as a replacement of RC4, as it address some of the problems with AES/CBC (known plaintext attack). Mark On Tue, 15 Sep 2015 11:22:22 -0400, Jim Starkey

[Firebird-devel] Crypto Performance

I've done some moderately careful performance apples to apples comparisons for various crypto functions with not very surprising results. In general: AES-NI < RC4 < ChaCha20 < AES (software) The two AES functions, the Botan software version and the DJ Bernstein NI (new instructions)

Re: [Firebird-devel] Crypto Performance

Jim, > 1. As Sean pointed out, the AES instructions are common on Intel > processors.  Not so for AMD, however, which only supports AES in their high > end server chips.  My HP AMD mini-tower, for example, doesn't have the > AES instruction set. It seems that AMD might be exaggerating their

Re: [Firebird-devel] Crypto Performance

On 9/15/2015 12:24 PM, Leyne, Sean wrote: > Jim, > >> I don't know of any known problems with AES/CBC. It is simply the most >> trusted crypto algorithm in the history of computing. It isn't possible >> prove >> that something can't be broken, but many, many very smart people have >> spent many

Re: [Firebird-devel] SET TRANSACTION in isql

Здравствуйте! Monday, September 14, 2015, 10:22:02 PM, you wrote: >>From my tests, it doesn't seem to be the case. It seems that, as soon as one >>commits or rolls back the started transaction, isql starts a new >>transaction using the global default (READ WRITE WAIT ISOLATION LEVEL

Re: [Firebird-devel] Crypto Performance

> None of these suggest that there is an attack -- read the comments. They refer to a possible attack and provide links to other sites. One of the sites has a link to the following: http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf which (at least to my scanned reading)

Re: [Firebird-devel] Different collation ID for alteredcomputedcolumn

> I told you it's fixed in v3. What do you want? Sorry. I saw only "Some bug fixed (intentionally or not) in v3." and from that I understood this "bug" was introduced by fixing another bug in v3. Maybe you meant something else. > It's different from v2.5, now collation goes to rdb$fields

Re: [Firebird-devel] Crypto Performance

On 9/15/2015 12:57 PM, Leyne, Sean wrote: > >> None of these suggest that there is an attack -- read the comments. > They refer to a possible attack and provide links to other sites. One of the > sites has a link to the following: > >

Re: [Firebird-devel] SET TRANSACTION in isql

> -Original Message- > From: Dmitry Kuzmenko [mailto:k...@ibase.ru] > Sent: Martes, 15 de Septiembre de 2015 7:47 > > default "no_rec_version" for read_committed also confuses people, > because it "blocks reading of concurrent uncommitted changes". > Jiri said that > "that was Dmitry

Re: [Firebird-devel] Different collation ID for alteredcomputedcolumn

On 15/09/2015 02:12, Jiří Činčura wrote: >> If a tool has a problem with that, tell the author to enhance it. The > Where can I ask for isql to be fixed - either disallowing generated > domains or showing proper output? ;) > > This is definitely interesting edge case, so I just thought I'll share