Eric Rescorla wrote:
E(M) || H(M)- This is still quite dangerous. If the attacker
can somehow reset the IV, then they can mount
an attack on the first cipher block.
Also, it can violate confidentiality. If M is guessable,
the guess can be confirmed
John S. Denker wrote:
More specifically, anybody who thinks the scheme
I described is vulnerable to a timing attack isn't
paying attention. I addressed this point several
times in my original note. All transmissions
adhere to a schedule -- independent of the amount,
timing, meaning, and other
Perry E. Metzger wrote:
I've noted to others on this before that for an application like
the IP fragmentation id, it might be even better if no repeats
occurred in any block of 2^31 (n being 32) but the sequence did not
repeat itself (or at least could be harmlessly reseeded at very very
long
John Doe Number Two wrote:
It's nice to see someone 'discovering' what Lucky Green already figured-out
years ago. I wonder if they'll cut him a check.
No, no, no! This is new work, novel and different from what was
previously known. In my opinion, it is an outstanding piece of research.
Vin McLellan wrote:
A5/2 was the equivalent of 40-bit DES, presumed to be relatively weak and
developed as an export standard.
Yeah. Except it would be more accurate to place A5/2's strength as
roughly equivalent to 17-bit DES. A5/1's strength is roughly equivalent
to that of 40-bit DES.
Of
One point your analysis misses is that there are public policy
implications to deploying a phone system that enemy countries can
routinely intercept. Not all attacks are financially motivated.
Is it a good thing for our infrastructure to be so insecure?
Do we want other countries listening to
martin f krafft wrote:
So MagiQ and others claim that the technology is theoretically
unbreakable. How so? If I have 20 bytes of data to send, and someone
reads the photon stream before the recipient, that someone will have
access to the 20 bytes before the recipient can look at the 20
bytes,
On 09/13/2003 05:06 PM, David Wagner wrote:
Quantum cryptography *assumes* that you
have an authentic, untamperable channel between sender and receiver.
Not true. The signal is continually checked for
tampering; no assumption need be made.
Quantum crypto only helps me exchange a key
Arnold G. Reinhold wrote:
I think there is another problem with quantum cryptography. Putting
aside the question of the physical channel, there is the black box at
either end that does all this magical quantum stuff. One has to trust
that black box.
- Its design has to thoroughly audited and
R. A. Hettinga wrote:
http://www.net-security.org/news.php?id=3583
Quantum cryptography finally commercialized?
Posted by Mirko Zorz - LogError
Tuesday, 16 September 2003, 1:23 PM CET
For the onlookers, this article is misinformed and should
not be relied upon for evaluating quantum
Tom Otvos wrote:
As far as I can glean, the general consensus in WYTM is that MITM
attacks are very low (read:
inconsequential) probability. Is this *really* true?
I'm not aware of any such consensus.
I suspect you'd get plenty of debate on this point.
But in any case, widespread exploitation of
Thor Lancelot Simon wrote:
Can you please posit an *exact* situation in which a man-in-the-middle
could steal the client's credit card number even in the presence of a
valid server certificate?
Sure. If I can assume you're talking about SSL/https as it is
typically used in ecommerce today,
Enzo Michelangeli wrote:
...one-way encryption algorithms guaranteed to be injective (i.e.,
deterministically collision-free)?
Every encryption algorithm is injective, otherwise decryption
would be ambiguous. In other words, if x and x' are two different
plaintexts, then E_k(x) != E_k(x').
I'm
martin f krafft wrote:
it came up lately in a discussion, and I couldn't put a name to it:
a means to use symmetric crypto without exchanging keys:
- Alice encrypts M with key A and sends it to Bob
- Bob encrypts A(M) with key B and sends it to Alice
- Alice decrypts B(A(M)) with key A,
Anton Stiglic wrote:
David Wagner [EMAIL PROTECTED] wrote:
martin f krafft wrote:
- Bob encrypts A(M) with key B and sends it to Alice
- Alice decrypts B(A(M)) with key A, leaving B(M), sends it to Bob
- Bob decrypts B(M) with key B leaving him with M.
Are there algorithms
Peter Fairbrother wrote:
Nope. In P-H there is no g. A ciphertext is M^k mod p. An attacker won't
know k, and usually won't know M, but see below. I don't know what the
problem is called, but it isn't DLP. Anyone?
Ok, I was being slightly loose. To be more precise, the security of
William Arbaugh wrote:
On Dec 16, 2003, at 5:14 PM, David Wagner wrote:
Jerrold Leichter wrote:
We've met the enemy, and he is us. *Any* secure computing kernel
that can do
the kinds of things we want out of secure computing kernels, can also
do the
kinds of things we *don't* want out
William Arbaugh wrote:
David Wagner writes:
As for remote attestion, it's true that it does not directly let a remote
party control your computer. I never claimed that. Rather, it enables
remote parties to exert control over your computer in a way that is
not possible without remote
Jerrold Leichter wrote:
| *Any* secure computing kernel that can do
| the kinds of things we want out of secure computing kernels, can also
| do the kinds of things we *don't* want out of secure computing kernels.
David Wagner wrote:
| It's not hard to build a secure kernel that doesn't provide
Jerrold Leichter wrote:
All of this is fine as long as there is a one-to-one association between
machines and owners of those machines. Consider the example I gave
earlier: A shared machine containing the standard distribution of the
trusted computing software. All the members of the group
Jani Nurminen wrote:
I had this idea about reversing the roles of the actors in a typical DRM
system, and thinking about where it might lead.
[...]
This kind of application of DRM would probably guarantee privacy of the
personal data of each individual person, while at the same time allow
Jerrold Leichter wrote:
Joux's attack says: Find single block messages M1 and M1' that collide on
the blank initial state. Now find messages M2 amd M2' that collide with
the (common) final state from M1 and M1'. Then you hav four 2-block
collisions for the cost of two: M1|M2, M1'|M2, and so
Hal Finney writes:
[John Denker proposes:] the Bi are the input blocks:
(IV) - B1 - B2 - B3 - ... Bk - H1
(IV) - B2 - B3 - ... Bk - B1 - H2
then we combine H1 and H2 nonlinearly.
This does not add any strength against Joux's attack. One can find
collisions for this in 80*2^80 time with
Hal Finney wrote:
[...] hard to verify signature [...]
Choose the number of modular squarings, t, that you want the verifier
to have to perform. Suppose you choose t = 1 billion. Now you will
sign your value using an RSA key whose exponent e = 2^t + 1.
The way you sign, even using such a large
Ian Grigg writes:
I note that disctinction well! Certificate based systems
are totally vulnerable to a passive sniffing attack if the
attacker can get the key. Whereas Diffie Hellman is not,
on the face of it. Very curious...
No, that is not accurate. Diffie-Hellman is also insecure if the
Ben Laurie writes:
Dan Kaminsky's recent posting seems to have caused some excitement, but
I really can't see why. In particular, the idea of having two different
executables with the same checksum has attracted attention.
But the only way I can see to exploit this would be to have code that
Ben Laurie writes:
Indeed, but what's the point? If you control the binary, just distribute
the malicious version in the first place.
Where this argument breaks down is that someone might have partial
but not total control over the binary. This partial control might
not be enough for them to
Florian Weimer [EMAIL PROTECTED] writes:
I'm slightly troubled by claims such as this one:
http://lists.debian.org/debian-devel/2004/12/msg01950.html
[which says: If you're going to use /dev/urandom then you might
as well just not encrypt the session at all.]
That claim is totally bogus,
John Denker writes:
Ben Laurie wrote:
http://www.apache-ssl.org/randomness.pdf
I just took a look at the first couple of pages.
IMHO it has much room for improvement.
I guess I have to take exception. I disagree. I think Ben Laurie's
paper is quite good. I thought your criticisms missed some
John Denker writes:
Well, of course indeed! That notion of entropy -- the entropy
in the adversary's frame of reference -- is precisely the
notion that is appropriate to any adversarial situation, as I
have consistently and clearly stated in my writings;
[...]
There is only one entropy that
In article [EMAIL PROTECTED] you write:
Voice Over Internet Protocol and Skype Security
Simson L. Garfinkel
http://www.soros.org/initiatives/information/articles_publications/articles/security_20050107/OSI_Skype5.pdf
Is Skype secure?
The answer appears to be, no one knows. The report accurately
Adam Shostack [EMAIL PROTECTED] writes:
On Mon, Jan 10, 2005 at 08:33:41PM -0800, David Wagner wrote:
| In article [EMAIL PROTECTED] you write:
| Voice Over Internet Protocol and Skype Security
| Is Skype secure?
|
| The answer appears to be, no one knows. The report accurately reports
Ben Laurie writes:
It was suggested at the SAAG meeting at the Minneapolis IETF that a way
to deal with weakness in hash functions was to create a new hash
function from the old like so:
H'(x)=Random || H(Random || x)
Yes. Suppose we use this for signing. The crucial part is to have
the
Ian G writes:
Collision resistance of message digests is effected by the birthday
paradox, but that does not effect pre-image resistance. (correct?)
So can we suggest that for pre-image resistance, the strength of
the SHA-1 algorithm may have been reduced from 160 to 149?
Well, I'm not sure
Jerrold Leichter writes:
They don't claim that:
This cipher is ... provably just as secure as AES-128.
I can come up with a cipher provably just as secure as AES-128 very quickly
Actually, I think Adam is totally right.
Have you looked at their scheme?
http://www.idcorner.org/index.php?p=88
The Identity Corner
Stephan Brands
I am genuinely excited about this
development, if it can be taken as an indication that Microsoft is getting
serious about privacy by design for identity management. That is a big
if, however: indeed, the same Microsoft
Anonymous wrote:
DTV Content Protection
[...] Similar concepts are presented in
http://apache.dataloss.nl/~fred/www.nunce.org/hdcp/hdcp111901.htm by
Scott Crosby, Ian Goldberg, Robert Johnson, Dawn Song and David Wagner.
This paper assumes (unlike Irwin) that attackers have access to the
private
Ben Laurie writes:
Why is it bad for the page to be downloaded clear? What matters is the
destination is encrypted, surely?
Because the page you downloaded in the clear contains the https: URL
in the post method. How do you know that this is the right URL? If
you got the page in the clear, you
Victor Duchovni wrote:
Joint works with [...]
Is it politically correct to not cite DJB in this context [...]
The phrase joint work with XXX means that this was a collaboration
between XXX and the speaker. If DJB wasn't part of the collaboration,
then of course he wouldn't be on that list.
Amir Herzberg writes:
However, quite a few of these sites invoke SSL/TLS only _after_ user has
typed in her user name and pw, and clicked `submit`. This allows a MITM
adversary to send a modified login page to the user, which sends the pw
to the attacker (rather than encrypting it and sending to
Travis writes:
The naive countermeasure to timing attacks is to add a random delay,
but of course that can be averaged out by repeating the computation.
I have never heard anyone propose a delay that is based on the input,
and maybe some per-machine secret, so that it is unpredictable but
So far I haven't seen any userland tools for updating the entropy count.
This is unfortunate, because sometimes I generate entropy on one machine
and want to pipe it into the /dev/random pool.
However, I cannot update entropy counts [...]
This is a security feature. If non-root programs could
Philipp G#ring [EMAIL PROTECTED] writes:
I have been asked by to verify the quality of the random numbers which are
used for certificate requests that are being sent to us, to make sure that
they are good enough, and we don´t issue certificates for weak keys.
Go tell whoever wrote your
John Denker [EMAIL PROTECTED] writes:
Werner Koch retorted:
I disagree strongly here. Any code which detects an impossible state
or an error clearly due to a programming error by the caller should
die as soon as possible.
That is a remarkably unprofessional suggestion. I hope the people
Richard Salz [EMAIL PROTECTED] wrote:
Today in slashdot (http://it.slashdot.org/it/06/06/12/0710232.shtml) there
was an article about China wanting to get WAPI accepted as a new wireless
security standard. Has anyone looked at it?
Adam Perez wrote:
I have not looked at WAPI, but they have been
hank you to everyone who corrected the errors in my earlier post. As has
been pointed out, the SMS4 block cipher was disclosed earlier this year.
Nonetheless, many of my concerns about the security of WAPI remain.
We already have a perfectly good solution out there; 802.11i is a good
scheme, and
The Irish government's commission's report on the NEDAP/Powervote system
has been published. (PDFs on the site)
http://www.cev.ie/htm/report/download_second.htm
As a secure system, it leaves a lot to be desired and it seems to be an
example in how not to implement an eVoting system. Just
Ondrej Mikle wrote:
I believe I have the proof that factorization of N=p*q (p, q prime) is
polynomially reducible to discrete logarithm problem. Is it a known fact
or not?
Be careful: when most people talk about the assumption that the
discrete log problem being hard, they usually are
[EMAIL PROTECTED]
Been with a reasonable number of General Counsels
on this sort of thing. Maybe you can blame them
and not SB1386 for saying that if you cannot prove
the data didn't spill then it is better corporate
risk management to act as if it did spill.
Well, are you sure you haven't
The algorithm is very simple:
1. Choose a big random value x from some very broad range
(say, {1,2,..,N^2}).
2. Pick a random element g (mod N).
3. Compute y = g^x (mod N).
4. Ask for the discrete log of y to the base g, and get back some
answer x' such that y = g^x' (mod N).
Danilo Gligoroski writes:
[...] solve a system of 3 polynomials of order 3
with 3 variables x1, x2 and x3 in the set Z_{2^32} and
coeficients also in Z_{2^32} [...]
Here is a trick that should solve these kinds of equations extremely
quickly. First, you solve the system of equations modulo 2.
James A. Donald [EMAIL PROTECTED] writes:
Parameters should not be expressed in the relevant part
of the signature. The only data that should be
encrypted with the RSA private key and decrypted with
the public key is the hash result itself, and the
padding. If the standard specifies that
Udhay Shankar reports:
http://news.zdnet.com/2100-1009_22-6142935.html
British start-up Yuzoz has announced that it will be launching its
beta service in the next two weeks--an online random-number generator
driven by astronomical events.
Heh heh. Pretty amusing. I guess the founders haven't
Jim Hughes writes:
The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability
that that are collisions that will divulge the mixing key which will reduce
the mode to ECB.
Peter Gutmann asks:
Is there any more information on this anywhere? I haven't been able to find
anything
Thanks to everyone who responded with more information about IEEE
P1619. Here are some of the additional links, with my reactions:
Andrea Pasquinucci points to:
http://en.wikipedia.org/wiki/IEEE_P1619#LRW_issue
Ben Laurie points to:
http://grouper.ieee.org/groups/1619/email/msg00558.html
Hagai Bar-El writes:
What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the real world -- they are outnumbered by
plain
Tim Dierks writes:
(there are totally different reasons that client certs aren't being
widely adopted, but that's beside the point).
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at
Crawford Nathan-HMGT87 writes:
One of the problems with the Linux random number generator
is that it happens to be quite slow, especially if you need a lot of
data.
/dev/urandom is blindingly fast. For most applications, that's
all you need.
(Of course there are many Linux applications that use
In article [EMAIL PROTECTED] you write:
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which
Florian Weimer writes:
I've got a function f : S - X x S where S = (Z/2Z)**96 and
X = (Z/2Z)**32. Suppose that s_0 is fixed and (x_i, s_i) = f(s_{i-1}).
(f implements a PRNG. The s_i are subsequent internal states and the
x_i are results.)
Now f happens to be linear. I know the values of
Matt Ball writes:
Another attacking avenue is the 32-bit initial seed. If the
implementation re-seeds frequently, or leaks to you the first outputs
after initialization, then you only have to brute-force the 32-bit
seed space, times the number of samples since reseeding.
Well, that's good and
Steve Bellovin writes:
Greg, assorted folks noted, way back when, that Skipjack looked a lot
like a stream cipher. Might it be vulnerable?
I'm still absorbing Adi's new ideas, and I haven't looked at this in any
detail, so anything I say should be taken with an enormous grain of salt.
But,
Santiago Aguiar wrote:
As I wrote in my last email, in Brazil they are devising a protocol to
activate tracking/blocking devices to be installed from factory in
*every* vehicle, starting progressively from august 2009. The idea is
that a service operator (SO) can activate a device to work
Assume for a moment that we have a random number generator which is
non-uniform, and we are using it to generate a key.
What I'd like to do is characterize the work factor involved in
brute-force search of the key space, assuming that the adversary
has knowledge of the characteristics of the
Alexander Klimov wrote:
A problem with this reasoning is that the physical world and the usual
digital computers have exponential simulation gap (it is known at
least in one direction: to simulate N entangled particles on a digital
computer one needs computations exponential in N). This can
Advice: if you're creating something for general-purpose use, at a minimum
make sure it provides authentication, integrity, *and* confidentiality.
A reasonable choice might be Encrypt-then-Authenticate where you first
encrypt with AES-CBC, then append a AES-CMAC message authentication
code on the
I don't exactly follow the argument for using CCM mode instead
AES-CBC encryption followed by AES-CMAC, and I'm not familiar with
the political/perception arguments (who complains about the latter?),
but whatever. It's hardly worth arguing over. The cryptographic mode
of operation is unlikely to
Florian Weimer wrote:
And you better randomize some bits covered by RRSIGs on DS RRsets.
Directly signing data supplied by non-trusted source is quite risky.
(It turns out that the current signing schemes have not been designed
for this type of application, but the general crypto community is
Jerry Leichter wrote:
CTR mode is dangerous unless you're also doing message authentication,
Nitpick:
That's true of CBC mode, too, and almost any other encryption mode.
Encryption without authentication is dangerous; if you need to encrypt,
you almost always need message authentication as
Alfonso De Gregorio wrote:
The last Thursday, Vincent Rijmen announced a new clever attack on
AES (and KASUMI) in a report posted to the Cryptology ePrint
Archive: Practical-Titled Attack on AES-128 Using Chosen-Text
Relations, http://eprint.iacr.org/2010/337
Jonathan Katz wrote:
Florian Weimer wrote:
* David McGrew:
can I ask what your interest in AEAD is? Is there a particular
application that you have in mind?
I just want to create a generic API which takes a key (most of the
time, a randomly generated session key) and can encrypt and decrypt
small blobs.
I've noticed quite a few questions on this list
recently of the form How do I do X? What is
the right cryptographic primitive for goal X? etc.
I'd like to plug the following site:
http://crypto.stackexchange.com/
Cryptography Stack Exchange
It is an excellent place to post questions like
that
72 matches
Mail list logo
