On 02/10/13 18:42, Arnold Reinhold wrote:
On 1 Oct 2013 23:48 Jerry Leichter wrote:
The larger the construction project, the tighter the limits on this stuff. I used to work with a former structural
engineer, and he repeated some of the bad example stories they are taught. A famous case a
On 10/02/2013 02:13 PM, Brian Gladman wrote:
The NIST specification only eliminated Rijndael options - none of the
Rijndael options included in AES were changed in any way by NIST.
Leaving aside the question of whether anyone weakened it, is it
true that AES-256 provides comparable security
On 10/2/13 at 7:16 AM, g...@kinostudios.com (Greg) wrote:
I'm interested in cases where Mailman passwords have been abused.
Show me one instance where a nuclear reactor was brought down
by an earthquake! Just one! Then I'll consider spending the $$
on it!
And while you're at it, show me
On Wed, 2 Oct 2013 10:16:42 -0400
Greg g...@kinostudios.com wrote:
I'm interested in cases where Mailman passwords have been abused.
Show me one instance where a nuclear reactor was brought down by an
earthquake! Just one! Then I'll consider spending the $$ on it!
Assume for a moment that
Hi,
Am 2013-09-30 10:16, schrieb ianG:
I'm not really understanding the need for checksums on keys.
Perhaps it is a DLP (Data Leakage Prevention) technology. At least the
same method works great for Creditcard numbers.
Oh, there is a 14 digit number being sent on a unclassified network,
and all
On 2013-10-03 00:46, John Kelsey wrote:
a. Most attacks come from protocol or mode failures, not so much crypto
primitive failures. That is, there's a reaction attack on the way CBC
encryption and message padding play with your application, and it doesn't
matter whether you're using AES or
Jerry Leichter leich...@lrw.com writes:
My favorite more recent example of the pitfalls is TL1, a language and
protocol used to managed high-end telecom equipment. TL1 has a completely
rigorous syntax definition, but is supposed to be readable.
For those not familiar with TL1, supposed to be
On 2013-10-02 23:09, Phillip Hallam-Baker wrote:
No, the reason for baring multiple inheritance is not that it is too
clever, it is that studies have shown that code using multiple
inheritance is much harder for other people to understand than code
using single inheritance.�
That is
On 2/10/13 17:46 PM, John Kelsey wrote:
Has anyone tried to systematically look at what has led to previous crypto
failures?
This has been a favourite topic of mine, ever since I discovered that
the entire foundation of SSL was built on theory, never confirmed in
practice. But my views are
I know others have already knocked this one down, but we are now in an
area where conspiracy theories are real, so for avoidance of doubt...
On 2/10/13 00:58 AM, Peter Fairbrother wrote:
AES, the latest-and-greatest block cipher, comes in two main forms -
AES-128 and AES-256.
AES-256 is
On 3/10/13 00:37 AM, Dave Horsfall wrote:
On Wed, 2 Oct 2013, Jerry Leichter wrote:
Always keep in mind - when you argue for easy readability - that one
of COBOL's design goals was for programs to be readable and
understandable by non-programmers.
Managers, in particular.
SQL, too, had
On 03/10/2013 04:13, Ray Dillinger wrote:
On 10/02/2013 02:13 PM, Brian Gladman wrote:
The NIST specification only eliminated Rijndael options - none of the
Rijndael options included in AES were changed in any way by NIST.
Leaving aside the question of whether anyone weakened it, is it
On Oct 3, 2013, at 10:09 AM, Brian Gladman b...@gladman.plus.com wrote:
Leaving aside the question of whether anyone weakened it, is it
true that AES-256 provides comparable security to AES-128?
I may be wrong about this, but if you are talking about the theoretical
strength of AES-256, then
For those not familiar with TL1, supposed to be readable here means
encoded in ASCII rather than binary. It's about as readable as
EDIFACT and HL7.
utter_tangent
The (U.S.) medical records system that started at the Veterans'
Administration and has now spread to all but all parts of the
On 2013-10-03 09:49, Peter Gutmann wrote:
Jerry Leichter leich...@lrw.com writes:
My favorite more recent example of the pitfalls is TL1, a language and
protocol used to managed high-end telecom equipment. TL1 has a completely
rigorous syntax definition, but is supposed to be readable.
On Thu, 3 Oct 2013, Peter Gutmann wrote:
For those not familiar with TL1, supposed to be readable here means
encoded in ASCII rather than binary. It's about as readable as
EDIFACT and HL7.
In a previous life I had to read, understand, and debug EDIFACT (it was
OpenLDAP, as I recall). It
On Wed, Oct 2, 2013 at 8:13 PM, Ray Dillinger b...@sonic.net wrote:
Leaving aside the question of whether anyone weakened it, is it
true that AES-256 provides comparable security to AES-128?
No, there's a common misconception that the related key attacks make
AES-256 worse than AES-128
On Thu, Oct 3, 2013 at 5:19 AM, ianG i...@iang.org wrote:
On 3/10/13 00:37 AM, Dave Horsfall wrote:
On Wed, 2 Oct 2013, Jerry Leichter wrote:
Always keep in mind - when you argue for easy readability - that one
of COBOL's design goals was for programs to be readable and
understandable by
On Oct 3, 2013, at 12:21 PM, Jerry Leichter leich...@lrw.com wrote:
As *practical attacks today*, these are of no interest - related key attacks
only apply in rather unrealistic scenarios, even a 2^119 strength is way
beyond any realistic attack, and no one would use a reduced-round version
IMO readability is very hard to measure. Likely things being where you
expect them to be, with minimal confusing characters but clear anchoring
so you can start reading from anywhere.
If someone could write a generative meta-language we can then ask people to
do text comprehension tasks on the
20 matches
Mail list logo
