> -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 Kuzm
> 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 instead
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:
>
> http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.
> 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) sugge
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
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
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.
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
wrote:
> I've done some
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 suppo
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) versi
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
Здравствуйте!
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
>>SNAPSHOT
12 matches
Mail list logo