On 10/11/13 7:34 PM, Peter Gutmann wrote:
Phillip Hallam-Baker hal...@gmail.com writes:
Quick question, anyone got a good scheme for key stretching?
http://lmgtfy.com/?q=hkdfl=1
Yeah, that's a weaker simplification of the method I've always
advocated, stopping the hash function before the
On 9/11/13 6:00 AM, Alexandre Anzala-Yamajako wrote:
Chacha20 being a stream cipher, the only requirement we have on the ICV is
that it doesn't repeat isn't ?
You mean IV, the Initialization Vector. ICV is the Integrity Check Value,
usually 32-64 bits appended to the packet. Each is
On 9/11/13 10:27 AM, Adam Langley wrote:
[attempt two, because I bounced off the mailing list the first time.]
On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Why generate the ICV key this way, instead of using a longer key blob
from TLS
On 9/11/13 10:37 AM, Adam Langley wrote:
On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Or you could use 16 bytes, and cover all the input fields There's no
reason the counter part has to start at 1.
It is the case that most of the bottom
It bugs me that so many of the input words are mostly zero. Using the
TLS Sequence Number for the nonce is certainly going to be mostly zero
bits. And the block counter is almost all zero bits, as you note,
(In the case of the TLS, limits on the plaintext size mean that the
first counter
Nicolas Williams wrote:
Getting DNSSEC deployed with sufficiently large KSKs should be priority #1.
I agree. Let's get something deployed, as that will lead to testing.
If 90 days for the 1024-bit ZSKs is too long, that can always be
reduced, or the ZSK keylength be increased -- we too can
Perry E. Metzger wrote:
[Snip admirably straightforward threat and requirements analysis]
Yes, you can attempt to gather randomness at run time, but there are
endless ways to screw that up -- can you *really* tell if your random
numbers are random enough? -- and in a cheap device with low
Jerry Leichter wrote:
...
accurately states that AES-128 is thought to be secure within the state
of current and expected cryptographic knowledge, it propagates the meme
of the short key length of only 128 bits. A key length of 128 bits is
beyond any conceivable brute force attack - in and
James A. Donald wrote:
Peter Gutmann wrote:
Unfortunately I think the only way it (and a pile of other things as
well) may get stamped out is through a multi-pronged approach that
includes legislation, and specifically properly thought-out
requirements
I agree. I'm sure this is a
It seems like enough time has passed to post publicly, as some of these
are now common knowledge:
Ben Laurie wrote:
William Allen Simpson wrote:
Keep in mind that the likely unpredictability is about 2**24. In many
or most cases, that will be implementation limited to 2**18 or less.
Why
I've changed the subject. Some of my own rants are about mathematical
cryptographers that are looking for the perfect solution, instead of
practical security solution. Always think about the threat first!
In this threat environment, the attacker is unlikely to have perfect
knowledge of the
We had many discussions about this 15 years ago
You usually have predictable plaintext. A cipher that isn't strong enough
against a chosen/known plaintext attack has too many other protocol
problems to worry about mere padding!
For IPsec, we originally specified random padding with 1
Francois Grieu wrote:
That's because if Tn is known (including chosen) to some person,
then (due to the weakness in MD5 we are talking about), she can
generate Dp and Dp' such that
S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' || Cp || Cn) )
whatever Cp, Cn and S() are.
First of all, the
Personally, I thought this horse was well drubbed, but the moderator let
this message through, so he must think it important to continue
James A. Donald wrote:
William Allen Simpson wrote:
The notary would never sign a hash generated by
somebody else. Instead, the notary generates its
James A. Donald wrote:
Not true. Because they are notarizing a signature, not
a document, they check my supporting identification,
but never read the document being signed.
This will be my last posting. You have refused several requests to stick
to the original topic at hand.
Apparently,
Weger, B.M.M. de wrote:
See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/
...
Our first chosen-prefix collision attack has complexity of about
2^50, as described in our EuroCrypt 2007 paper. This has been
considerably improved since then. In the full paper that is in
preparation
James A. Donald wrote:
This attack does not require the certifier to be
compromised.
You are referring to a different page (that I did not reference).
Never-the-less, both attacks require the certifier to be compromised!
The attack was to generate a multitude of predictions
for the US
Weger, B.M.M. de wrote:
The parlor trick demonstrates a weakness of the pdf format, not MD5.
I disagree. We could just as easy have put the collision blocks
in visible images.
Parlor trick.
... We could just as easy have used MS Word
documents, or any document format in which there is some
I often say, Rub a pair of cryptographers together, and you'll
get three opinions. Ask three, you'll get six opinions. :-)
However, he's talking about security, which often isn't quantifiable!
And don't get me ranting about provable security Had a small
disagreement with somebody at
Leichter, Jerry wrote:
| note that there have been (at least) two countermeasures to DES brute-force
| attacks ... one is 3DES ... and the other ... mandated for some ATM networks,
| has been DUKPT. while DUKPT doesn't change the difficulty of brute-force
| attack on single key ... it creates a
http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html
The vulnerability allows an attacker to exhaust the IKE resources on a
remote VPN concentrator by starting new IKE sessions faster than the
concentrator expires them from its queue. By doing this, the attacker
fills up the
Perry E. Metzger wrote:
http://www.usatoday.com/news/washington/2006-05-10-nsa_x.htm
Legal analysis from Center for Democracy and Technology at:
http://www.cdt.org/publications/policyposts/2006/8
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
.
Of course, AFAICT, the trailing key makes the various recent attacks
on MD5 and SHA1 entirely inapplicable.
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography Mailing
]):
Date: Sun, 15 Aug 1999 10:00:01 -0400
From: William Allen Simpson [EMAIL PROTECTED]
Catching up, and after talking with John Kelsey and Sandy Harris at
SAC'99, it seems clear that there is some consensus on these lists that
the semantics of /dev/urandom need improvement
is the community to replace ISAKMP with something more robust?
Provos' Photuris code could be running on all the BSDs in a few months.
Maybe sooner, were payment involved.
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
.
Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris
was written before the existence of ISAKMP.
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography
considerations.
Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and
graduate (Spatscheck, Provos) students independently were able to
complete interoperable implementations (in their spare time) in a
month or so
So, no, some security folks didn't ignore this ;-)
--
William Allen
for prime time.
(seen at http://isthatlegal.org)
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL
on the chin, and stick in the random(5)
page the description of how reliable the device
meets the requirement.
(This might be a resend, my net was dropping all
sorts of stuff today and I lost the original.)
That's OK, the writing was clearer the second time around.
--
William Allen Simpson
Key
and magic numbers, generally transmitted
verbatum. However, since we have a ready source of non-blocking keying
material in /dev/urandom, it seems to be better to use that instead of
the blocking critical resource
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9
phone
conversations that are temporarily stored in electronic routers
during transmission.
[page 51-52]
As this is a US Court of Appeals, it sets precedent that other courts
will use, and directly applies to all ISPs in the NE US.
--
William Allen Simpson
Key fingerprint = 17 40 5E 67
for a reversal.
It's pretty damn rare, he said. I have never seen it happen.
...
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography Mailing List
Unsubscribe by sending
!
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
both the user and administrator configure a per
host secret was apparently out of the question.
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-
The Cryptography Mailing List
34 matches
Mail list logo
