.)
The keep-alive extension to the HTTP protocol was
intended to make HTTP activity more TCP like.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
8PdgpCY8lcy6qRnKRQ4rc2g1XHLHgfmlDh2ajbn/
4Tdc/z1dVOW8Pb51y7ZwS1xLayi1u3YmFU8aAvRdv
TCP behavior with communications
that for which TCP is good (transferring large files)
and that approximates UDP with communications for which
UDP is good.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
CA0JQkWZ0L1FZxznjfOXmVHVt4WiIwUva7ci5uD5
mail.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
htNnuqbJ9fv6n64IRfD1zA7lLKKr2izEKeU8gcTj
4VIaWftcnkDyBJkkmq5thq8hruA/YIkpnczdJ3kzD
-
The Cryptography Mailing List
Unsubscribe
Leichter, Jerry wrote:
| It is known, that given such an oracle, the attacker can ask for
| decryption of all primes less than B, and then he will be able to
| sign PKCS-1 encoded messages if the representative number is B-smooth,
| but is there any way to actually recover d itself?
RSA is
DNS?
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
fLselD6l8fdbF1p4sjg3RQ2GXi+NnQ//1CymnfKs
4+JAX1zwW3fSIStp6glgbAygK1zCuoMeiTigr4qmd
-
The Cryptography Mailing List
Unsubscribe
--
James A. Donald:
One way of doing this would be for the MTA to insist
on a valid signature when talking to certain well
known MTAs, and then my MUA could whitelist mail
sent from those well known MTAs
Paul Hoffman wrote:
Yes, if you are willing to throw out messages whose
knows P(k), except for P(0), and can
intercept all transmitted values T(k).
Because the combination of addition and bitwise logical
operations is non linear, this method gets through a
loophole in Jutla's proof in
http://eprint.iacr.org/2000/039
--digsig
James A. Donald
6YeGpsZR
Typo:
James A. Donald wrote:
Let P(k) be the kth block of plain text. We prepend a
random block, P(0) to the text, and append a fixed block
to the end. If anything is altered, the fixed block at
the end will not contain the expected data, but will be
gibberish.
The adversary knows every
Simon Josefsson wrote:
Jostein Tveit [EMAIL PROTECTED] writes:
Anyone got a test key with a real and a forged signature to test
other implementations than OpenSSL?
There are actually two problems to consider...
First, there is the situation by Bleichenbacher at Crypto 06 and
explained in:
Why the exponent 3 error happened:
The signature consists of a number that when cubed, is
equal modulo N to the padded hash of the quantity to be
signed.
Part of the padding is the ASN.1 encoding of the hash.
Now suppose we had not ASN.1 encoded the hash.
Suppose the padding was simply
--
Greg Rose wrote:
At 19:02 +1000 2006/09/14, James A. Donald wrote:
Suppose the padding was simply
010101010101010 ... 1010101010101 hash
with all leading zeros in the hash omitted, and four
zero bits showing where the actual hash begins.
Then the error would never have been
.1 serves absolutely
no purpose whatsoever, other than to create complexity,
bugs, and opportunities for attack. It is sheer
pointless stupidity, complexity for the sake of
complexity, an indication that the standards process is
broken.
--digsig
James A. Donald
6YeGpsZR+nOTh
. If the standard specifies that additional
material should be encrypted, the standard is in error
and no one should follow it.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
sVNWfKHHWrogEro6rkjKzE2XEHGqyk1tXLiayWU7
4joW/r8h3DIfdlwaI5up/06PSaWuhEtwMmF9TsuGR
--
James A. Donald wrote:
Code is going wrong because ASN.1 can contain
complicated malicious information to cause code to go
wrong. If we do not have that information, or simply
ignore it, no problem.
Ben Laurie wrote:
This is incorrect. The simple form of the attack is
exactly
validation.
RFC-2440 actually gives the exact bytes to use for the
ASN.1 stuff, which nicely cuts down on ambiguity.
This amounts to *not* using ASN.1 - treating the ASN.1
data as mere arbitrary padding bits, devoid of
information content.
--digsig
James A. Donald
6YeGpsZR+nOTh
--
James A. Donald
We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
means bitwise or, curly brace means encryption.
Should read: We transmit T(k) = {W(k)} +
((~W(k-11){W(k-1)}) where ~ means bitwise negation,
| means bitwise or, curly brace means encryption.
Travis H. wrote
--
James A. Donald wrote:
Code is going wrong because ASN.1 can contain
complicated malicious information to cause code
to go wrong. If we do not have that
information, or simply ignore it, no problem.
Ben Laurie wrote:
This is incorrect. The simple form of the attack
by this process.
I don't think there's anything inherently wrong with
ASN.1 DER in crypto applications.
If there are no options, you are not using ASN.1 DER.
You are using some random padding bytes that happen to
be equal to ASN.1 DER.
--digsig
James A. Donald
6YeGpsZR+nOTh
--
Whyte, William wrote:
Anyway, the attack applies even if you throw away the
ASN.1 data.
If you ignore the ASN.1 data you expect the hash to be
in a fixed byte position, so the attack does not apply.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
, and allowed for no future expansion.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
/zedskWwjM7YJCe3zo2C7y0GDwUQjP+BN9ayEeww
4Y0kilizvKF0KpOu7fT86djxwW1ghxrvqfCKm1sKc
-
The Cryptography
a decoder for PKCS#1 v1.5, realized it
probably had bugs I wouldn't figure out until too
late, [...] my PSS verification code is probably
around twice the length of the PSS generation code,
due to the need to check every stupid little thing.
--digsig
James A. Donald
6YeGpsZR
are often highly user
unfriendly, and in consequence seldom used correctly.
Come to think of it, we have the same problem on the
internet.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
c/n1W5sl/AyzClfoXunWJSJOHHUhW1DmgUQG8ZC3
.
Therefore, in the context of ASN.1, the correct
interpretation of the specification is to allow for
arbitrary expansion - which is a bad spec.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
uTSBsEVoGqap3qSR80twUH+gg5Q8MDBgQhB2Wyxw
On 9/9/06, Adam Back [EMAIL PROTECTED] wrote:
IGE if this description summarized by Travis is correct, appears to be
a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
However the FREE-MAC mode (below described as IGE) was broken back in
Mar 2000 or maybe earlier by Gligor,
Lynn Wheeler wrote:
recently published IETF RFC
... from my IETF RFC index
http://www.garlic.com/~lynn/rfcietff.htm
4686 I
Analysis of Threats Motivating DomainKeys Identified
Mail (DKIM),
Fenton J., 2006/09/26 (29pp) (.txt=70382) (Refs
1939, 2821, 2822, 3501, 4033) (was
James A. Donald wrote:
In order for [DKIM] to actually be any use, the
recipient needs to verify the signature and do
something on the basis of that signature -
presumably whitelist email that genuinely comes from
well known domains.
Unfortunately, the MTA cannot reliably do
this matter.)
I was unaware that law enforcement does anything about
DoS attacks.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
J/PQ9VnDD/6V3E2EFdJ5YlRKN1f8VW3eeiOrlW0n
4ZN9+U3RbPuc6REG0rZS2Bz/81I7N5FBe2J2FMkrR
Erik Tews wrote:
What you do is, you trust your TPM and your BIOS that they never lie to
you, because they are certified by the manufature of the system and the
tpm. (This is why it is called trusted computing)
So if you don't trust your hardware and your manufactor, trusted
computing is
not come up at all.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
mzJSAlA4uoeaqcIPwxmdSTaMGpCr10BSXet2rKo+
4C0qq8mGmz37gK89YinlEpVVumD1TtkcDOd8iHHGh
-
The Cryptography Mailing
James A. Donald:
Well obviously I trust myself, and do not trust
anyone else all that much, so if I am the user, what
good is trusted computing?
One use is that I can know that my operating system
has not changed behind the scenes, perhaps by a
rootkit, know that not only have I
Travis H. wrote:
So I was reading about the OTP system (based on S/Key) described in RFC
2289.
It basically hashes a secret several times (with salt to individualize
it) and stores
the value that the correct password will hash to.
Now my question is, if we restrict ourselves to, say, 160-bit
I think Citibank aims at foot and lets loose with both barrels, then reloads
and shoots a second time would be a better title. This is a really scary
example of what Perry once referred to as banks actively training users to
become future victims of phishing attacks. What's even worse is
, though a different kind of subtlety.
The failure of Andersen and Enron is not being fixed,
and the failures we are looking at on this list - the
Citibank e-mail - are not being fixed either.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
eE+Hr
Matthias Bruestle wrote:
Hi,
I am thinking about this since last night. On the web I haven't found
much and I want to go in a different direction as I have found.
Say I want to have 112bit security, i.e. as secure as 3DES. For this I
would choose (as everybody writes) 224bit ECC (or Tipsy
made by earlier by many on this list and related lists
that PKI fulfills its specification just fine. The DRM
people wanted something that could not be done, so
unsurprisingly they winded up buying something that does
not do it.
--digsig
James A. Donald
6YeGpsZR+nOTh
Steven M. Bellovin wrote:
The AV decision is more problematic. While a good
security model can prevent system files from being
overwritten, most worms use purely user-level
abilities. It would take a fairly radical OS design
to prevent a user-level worm from spreading.
It is a fairly
.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
x4p2u5+Go3URK4IvzoJkO/+K0lr4p4XW2aNmlbEi
4dlOW8vAN4GsnWBzDGfvyjQYPosBfDEqrH3rKQ451
-
The Cryptography Mailing List
Unsubscribe by sending
checks make it
impossible to compile code that is bad in certain ways -
again a big project.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
txnLOsPeyJqwn5LYEMAdBUQoBArt6OJO8Rp8P6Vn
4GQB25JeUovLVxb1JZBHA6Q0qjCGFQGkhchihumVh
when
they get such a message, and at best they present an
opaque, incomprehensible, and useless interface. Has
anyone done marketing studies to see why banks and
massively phished organizations do not sign their
messages to their customers?
--digsig
James A. Donald
6YeGpsZR+nOTh
Ivan Krstić wrote:
This is, in my experience, exactly right. I'm trying
to take some steps for the better on the OLPC: all
e-mails and IMs will be signed transparently and by
default, with the possibility of being encrypted by
default in countries where it's not a problem. This'll
help with
Ed Gerck wrote:
I am using this insight in a secure email solution that provides
just that -- a reference point that the user trusts, both sending
and receiving email. Without such reference point, the user can
easily fall prey to con games. Trust begins as self-trust. Anyone
interested in
.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
hHUR4oItlqyjOJrgB5g69WubFGEXSD2fFY+PslCK
4pIw1gBia7di4K0uJB1p+FcZC9yxi1vCIFI3tot1u
-
The Cryptography Mailing List
Unsubscribe by sending
information, rather than true name
information.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
NMb/3lhm5wj1jn9bea0UJsViLkPWzA2jR+GCOgFV
4WdwEv3Qp46Bt5AR7KTqFUUnJqu7E/XHnkKfJ2t/D
.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
hyNNu45kHRCn/6vEXQhYdbU/w1YW4J/TF8BDsJz0
495s+VYSd3RjDiopACgr9JccOdvE7cTtQV6xgA8sK
-
The Cryptography Mailing List
Unsubscribe by sending
Nicolas Williams wrote:
Which means that the MITM would need the cooperation
of the client's provider in many/most cases (a
political problem) in order to be able to quickly get
in the middle so close to a leaf node (a technical
problem).
Not a very large political problem. Most ISPs not
Florian Weimer wrote:
With sign, then encrypt, it's also possible that the receiver decrypts
the message, and then leaks it, potentially giving the impression that
the signer authorized the disclosure. There has been a fair bit of
buzz about this confusion. But the lesson from that seems to be
Jason Holt wrote:
So I guess the answer to your question is We'd better
assume that DRM+TPM will be ineffective until we've
subjected a specific implementation of it to the same
level of scrutiny we apply to other cryptosystems, and
since DRM+TPM proposals tend to be much more
complicated
James A. Donald:
Assume Ann's secret key is a, and her public key is A
= G^a mod P
Assume Bob's secret key is b, and his public key is B
= G^b mod P
Bob wants to send Ann a message.
Bob generates a secret random number x, and sends Ann
X = G^x mod P
Ann responds with Y = G
--
Anne Lynn Wheeler wrote:
So one of the proposals (somewhat backed by the domain
name certification authority industry) is that domain
name owners place a public key on file when they
register a domain name with the domain name
infrastructure. They all future communication with the
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
Why?
Presumably both ends of the conversation have negotiated what protocol
version they are using (and if they have not, you have big problems) and
when they receive data, they
Initially I did not believe it, thought it must be hype or hoax.
Nope, it is a rootkit in hardware.
http://www.intel.com/business/vpro/index.htm
: : Isolate security tasks—in a separate
: : environment that is hidden to the user
: :
: : [...]
: :
: : Perform hardware and
James A. Donald wrote:
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
Why?
Presumably both ends of the conversation have negotiated what protocol
version they are using (and if they have not, you have big problems) and
when
James A. Donald:
Is anyone aware of a commercial product that
implements secret sharing? If so, can I get a
pointer to some product literature?
Peter Gutmann
It's available as part of other products (e.g. nCipher
do it for keying their HSMs), but I don't know of any
product that just
James A. Donald:
In the case of XML, yes there is a parsing engine,
and if the structure of the DTD reflects the
structure of the algorithm, then indeed it makes
things much easier. But usually the committee have
not thought about the algorithm, or have unresolved
disagreements about
Philipp � wrote:
* An external device that lets the user verify the transaction independently
from the PC.
The second possiblity has been realized by some european banks now, based on
SMS and mobile phones, which sends the important transaction details together
with a random authorisation
--
Steven M. Bellovin wrote:
http://www.tgdaily.com/content/view/33425/118/
Ann Arbor (MI) - University of Michigan scientists
have discovered a breakthrough way to utilize light in
cryptography. The new technique can crack even complex
codes in a matter of seconds. Scientists believe
Victor Duchovni wrote:
This part is not too radical. The more specific
skepticism of security proofs (I am reluctant to agree
that these are actively harmful), seems to be a
combination of the peer review issue above, and
(often?) lack of tight bounds that make the proofs
applicable to
If a proof is a record of a mental journey in which one person has
discovered an important truth, and then made a record of that journey
adequate so that a second person can walk the same path and see the same
truth, then cryptography could do with more and better proofs.
If, on the other
Netsecurity wrote:
Back in the late 60's I was playing with audio and a
magazine I subscribed to had a circuit for creating
warble tones for standing wave and room resonance
testing.
The relevance of this is that they were using a
random noise generating chip that they acknowledged
was
in ECMQV, how are they going
to justify the claim that it somehow really is ECMQV?
Note that that point compression avoids the attacks that
motivate ECMQV has not been examined in the literature,
nor have patent lawyers looked at any of the information
I present here.
--digsig
James
A 307 digit number is 1024 bits, near enough. 1024 bits
was scheduled to fail in 2013. It has failed early, due
to modest advances in factorization.
Thus past comparisons of the strength of encryption key
sizes are no longer entirely accurate. Further, they
never were that accurate to start
[EMAIL PROTECTED] wrote:
AFAIK, the only advantage of ECC is that the keys are shorter.
The disadvantage is that it isn't as well studied.
Nate Lawson wrote:
Again, this is well covered. The reason is the fundamental difference
in the performance of the best-known attacks (GNFS vs. Pollard's
since any such has been discovered for elliptic
curves, long enough to give a plausible hope that no
further such will ever be discovered.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
ibAQXQ+Yoy5neOvRwKJwdxVLDGSPwTxKobkv566h
4khPsLmyqlil
| AFAIK, the only advantage of ECC is that the keys are
| shorter. The disadvantage is that it isn't as well
| studied.
|
James A. Donald:
| On past performance, elliptic curves are safer than
| integers. From time to time, integer based asymmetric
| encryption is abruptly
an G wrote:
I was involved in one case where super-secret stuff
was shared through hushmail, and was also dual
encrypted with non-hushmail-PGP for added security.
In the end, the lawyers came in and scarfed up the
lot with subpoenas ... all the secrets were revealed
to everyone they should
[EMAIL PROTECTED] wrote:
The extra messages might be irrelevant for
cryptography, but they're not irrelevant for security
or functionality.
E.g. in SSL, you have capability/feature negotiation
(cipher suites, trusted CAs, in TLS 1.2 also signature
algorithms, etc.)
You can handle this by
' =JeffH ' wrote:
Adi Shamir Computer Science Department The Weizmann
Institute of Science Israel
With the increasing word size and sophisticated
optimizations of multiplication units in modern
microprocessors, it becomes increasingly likely that
they contain some undetected bugs. This was
James Muir wrote:
Can anyone think of a deployed implementation of RSA
signatures that would be vulnerable to the attack
Shamir mentions? Hashing and message blinding would
seem to thwart it.
As I said, public key encryption has long been known to
be weak against chosen plaintext and chosen
[EMAIL PROTECTED] wrote:
The obvious way - doing a specific step just to verify
the handshake - is the kind of code-centric thinking
that I'm trying to avoid. I'm having trouble finding
the right words for it. Basically an encrypted
network protocol is a language in which a transmission
William Allen Simpson wrote:
The notary would never sign a hash generated by
somebody else. Instead, the notary generates its own
document (from its own tuples), and signs its own
document, documenting that some other document was
submitted by some person before some particular time.
And
time.
James A. Donald:
And how does it identify this other document?
William Allen Simpson wrote:
Sorry, obviously I incorrectly assumed that we're
talking to somebody skilled in the art
Reminding you that several of us have told you that a
notary has the document in her possession
Steven M. Bellovin wrote:
It's moderately complex if you're trying to conserve bandwidth (which
translates to power) and preserve a datagram model. The latter
constraint generally rules out stream ciphers; the former rules out
things like encrypting the keystroke plus seven random bytes with a
Steven M. Bellovin wrote:
Believe it or not, I thought of CFB...
Sending keep-alives will do nasties to battery
lifetime, I suspect; most of the time, you're not
typing. As for CFB -- with a 64-bit block cipher (you
want them to use DES? they're not going to think of
anything different),
William Allen Simpson wrote:
The whole point of a notary is to bind a document to a
person. That the person submitted two or more
different documents at different times is readily
observable. After all, the notary has the
document(s)!
The notary does not want to have the documents, or to
Perry E. Metzger wrote:
I think Steve is completely correct in the case of
cryptography. We have a lot of experience of real
world security failures these days, and they're not
generally the sort that crypto would fix.
They are the sort that a different sort of way of using
crypto could fix.
Alex Alten wrote:
Generally any standard encrypted protocols will
probably eventually have to support some sort of CALEA
capability. For example, using a Verisign ICA
certificate to do MITM of SSL, or possibly requiring
Ebay to provide some sort of legal access to Skype
private keys.
And
Perry E. Metzger wrote:
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
http://www.freedom-to-tinker.com/?p=1250
The Dutch
Perry E. Metzger wrote:
The call-the-customer-and-reissue mechanism is a
mediocre solution to the fraud problem, but it is the
one we have these days.
Why is it a mediocre solution?
The credit card number is a widely shared secret. It
has been known for centuries that widely shared secrets
Ivan Krstic' wrote:
Some number of these muppets approached me over the
last couple of years offering to donate a free license
for their excellent products. I used to be more polite
about it, but nowadays I ask that they Google the
famous Gutmann Sound Wave Therapy[0] and mail me
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
Richard Salz wrote:
Perhaps theoretically painful, but in practice this is
not the case; commerce
Eric Rescorla wrote:
Huh? What are you claiming the problem with sending
client certificates in plaintext is (as if anyone uses
client certificates anyway)?
Well that is one problem - no one uses them, and no one
should use them, while PKI was designed under the
assumption that everyone would
Perry E. Metzger wrote:
(No, I'm not a fan of X.509 certs, but those are not
core to the protocol, and you can think of them as
nothing more than a fancy key container format if you
like. Key management is not addressed by SSL, so there
is no reason that fixing key management has anything
Guus Sliepen wrote:
Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
at Peter's write-up more objectively and I can see that it is not as
Victor Duchovni wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design)
adds round-trips to SSL warrants some evidence (it is very temping to
express this skepticism more bluntly).
With unextended SMTP for example, the minimum RTT count is:
0. SYN SYN-ACK
--
Ivan Krstic' wrote:
The wider point of Peter's writeup -- and of the
therapy -- is that developers working on security
tools should _know_ they're working in a notoriously,
infamously hard field where the odds are
_overwhelmingly_ against them if they choose to
engineer new
James A. Donald wrote:
I have figured out a solution, which I may post here
if you are interested.
Ian G wrote:
I'm interested. FTR, zooko and I worked on part of
the problem, documented briefly here:
http://www.webfunds.org/guide/sdp/index.html
I have posted How to do VPNs right at
http
Nicolas Williams wrote:
Sounds a bit like SCTP, with crypto thrown in.
SCTP is what we should have done http over, though of
course SCTP did not exist back then. Perhaps, like
quite a few other standards, it still does not quite
exist.
I thought it was the latency cause by unnecessary
Steven M. Bellovin wrote:
There's another issue: initial account setup. [Even
with SRP] people will still need to rely on
certificate-checking for that. It's a real problem at
some hotspots, where Evil Twin attacks are easy and
lots of casual users are signing up for the first
time.
For
From time to time I hear that DNSSEC is working fine, and on examining
the matter I find it is working fine except that
Seems to me that if DNSSEC is actually working fine, I should be able to
provide an authoritative public key for any domain name I control, and
should be able to obtain
Ben Laurie wrote:
Then we get to the next problem: we don't trust the
device with the keypad and display. So, we need to add
that to the GTCYM (Gadget That Controls Your Money).
And so we end up at the position that we have ended up
at so many times before: the GTCYM has to have a
decent
Ivan Krsti? wrote:
1. take partially known plaintext
2. make a guess, randomly or more intelligently where possible,
about the unknown parts
3. take the current integrated partial+guessed plaintext, hash
to obtain convergence key
4. verify whether that key exists in the storage index
5. if
Thor Lancelot Simon wrote:
It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.
I cannot help repeatedly noting that -- I believe more so than with actual
IPsec
Steven M. Bellovin wrote:
IPsec operates at layer 3, where there are (generally)
no user contexts. This makes it difficult to bind
IPsec credentials to a user, which means that it
inherently can't be as simple to configure as ssh.
Put another way, when you tell an sshd whom you wish
to
Thor Lancelot Simon wrote:
And, in fact, most VPN software of any type fails this test. My concern
is that an excessive focus on how hard is it to set this thing up? can
seriously obscure the important second half of the question and if you
set it up in the easiest possible way, is it safe?
Perry E. Metzger wrote:
What you can't do, full stop, is
know that there are no unexpected security related behaviors in the
hardware or software. That's just not possible.
Ben Laurie wrote:
Rice's theorem says you can't _always_ solve this problem. It says
nothing about figuring out
The same is true in the source code, unsafe
practices are avoided globally, (e.g. both strcpy()
and strncpy() are absent together with fixed size
automatic buffers) rather than used with care
locally. I won't bore you with all the
implementation safety habits, but there are many.
Arshad Noor wrote:
While programmers or business=people could be ill-informed, Allen,
I think the greater danger is that IT auditors do not know enough
about cryptography, and consequently pass unsafe business processes
and/or software as being secure.
Committees of experts regularly get
Peter Gutmann wrote:
For most crypto protocols, usability is job #8,107,
right after did we get the punctuation right in the footnotes for the third
appendix?.
Usability disasters such as DNSSEC are more common than strictly
cryptographic disasters such as wifi. DNSSEC is near impossible to
http://www.youtube.com/watch?v=NW3RGbQTLhE shows the researchers
breaking Mifare.
And in the comments, we see posts (I presume from mifare people)
complaining that what is happening cannot possibly be happening.
Everyone on this list knows the correct way to do what Mifare does wrong.
So,
Michael Tschannen wrote:
Hi list
Has anybody already gained experience concerning the technical
implementation of SRP (http://srp.stanford.edu)? There is one point I
couldn't find in any documentation: Should the modulus and the generator
(N and g) be unique for each client or can they be
101 - 200 of 304 matches
Mail list logo
