13.07.2010 13:38, Jaap Akkerhuis пишет:
That's the same software. If b-rail.be is competent about
updating its route database with other companies' trains, then
the results will be exactly as good as for bahn.de.
In that case, give ns.nl (dutch railways) a try. They seem to list
Andrew G. Malis пишет:
I'm with Joe on this. I also travel extensively, including in
non-tourist areas, and have never had my US Visa or Mastercard
declined because it didn't have a chip.
In Amsterdam there are shops (e.g. nice cheese shop ;) ) which accept
only local chip cards.
At the same
Ole Jacobsen пишет:
The PIN codes issued by US banks are for cash advances only, they are
NOT the required PIN code that European credit cards use and won't
work if you try to use them for a regular credit card payment. US
cards do not (in general) require a PIN code for credit card payments.
+1
John C Klensin пишет:
+1
Well, OK. Let me rephrase my question: why do you believe
that removing the IETF's MX record will
a) decrease the amount of spam it receives?
b) not damage its legitimate mail flow?
Based on my experience and that of other people, neither is
true.
R's,
Paul Wouters пишет:
DNSSEC declares out of scope:
* the channel where DS records get added to the parent
Is that actually out of scope or just not specified yet?
Out of scope. It is the bootstrap problem. Though with RFC-5011
It is much more than bootstrap problem.
and perhaps
Masataka Ohta пишет:
But, the most serious defect of DNSSEC, or PKI in general, is that,
despite a lot of hypes, it is not cryptographically secure.
Social attacks on trusted third parties makes the parties
untrustworthy, which means PKI is merely socially or weakly
secure.
There are a lot
Masataka Ohta :
Basil Dolmatov wrote:
There are a lot of deficiencies in PKI, but at present time I can see no
alternative for establishing trust in loosely connected and large
systems. If there is one, please advise.
The problem of PKI is that its security socially
Martin Rex wrote:
DNSsec, as far as I can see, does not use a PKI in the traditional
sense. There are _NO_ persons involved in the process,
I can see some... ;)
Any operation which is placed out-of-band of DNSSec requires some
trusted manual intervention.
Just for example:
First
Martin Rex пишет:
What I don't understand is whether the deprecation applies to
GOST R34.10-1994 in general,
Yes.
or only to GOST R34.10-1994 as a
signature algorithm.
No.
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST
Martin Rex :
Basil Dolmatov wrote:
Martin Rex :
Whether and how much the -1994 version is
deprecated is also a complete mystery.
It is written in the text of GOST -2001
Which document are you refering to when you say "text of GOST
Martin Rex пишет:
I'm still quite confused.
All references to GOST signature algorithms of the kind [GOST3410] ought to be
fixed to say [GOST3410-2001].
I think that can de done, despite the fact that there is no other
algorithm coded as GOST 3410, except GOST 34.10-2001.
It seems it
Martin Rex пишет:
Admittedly, I know very little about the cryptographic
details, but there are two GOST signature algorithms
(GOST R34.10-1994 and GOST R34.10-2001). The earlier
appears to bear some similarity with DH, the newer appears to bear
similarity with ECDH.
Whether and how much
Paul Hoffman пишет:
For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512.
That attack lessens the complexity of building of the collision from
2**128 operations to 2**109 operations (infinitesimal part of overall
13 matches
Mail list logo
