.
In addition, we also need to avoid to add fuel to that misconception,
that encryption is somehow dangerous or should be controlled
as weapons are. The only function of a weapon is to inflict harm.
The only function of encryption is to provide privacy.
Cheers,
Ed Gerck
a source. The rating system would reset the source rating
after a pre-defined time, much like anti-congestion mechanisms on the Net.
Fast rejection of bogus signatures would help, but not alone.
Cheers,
Ed Gerck
Bill Frantz wrote:
I have been thinking about how to limit denial of service
Windows and killed IBM's OS/2 in the process.
3. Embedding keys in mass-produced chips has
great sales potential. Now we may have to upgrade
processors also because the key is compromised ;-)
Cheers,
Ed Gerck
PS: We would be much better off with OS/2, IMO.
Ross Anderson wrote:
http
,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
is IMO a good example.
Comments?
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the browser does not use *any* root CA cert unless you sign
it first.
Thanks for your nice comment ;-)
Ed Gerck
Peter wrote:
I disagree with your first sentence (I believe that Pd must be trustworthy
for *the user*), but I like much of the rest of the first paragraph.
I am not sure what value my
statistics of small spheres.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
take a look at:
http://www.rsasecurity.com/products/mobile/datasheets/SIDMOB_DS_0802.pdf
and http://nma.com/zsentry/
Microsoft's move is good, RSA gets a good ride too, and the door may open
for a standards-based two-channel authentication method.
Cheers,
Ed Gerck
Roy M.Silvernail wrote
://nma.com/papers/it-trust-part1.pdf )
Cheers,
Ed Gerck
Arnold Reinhold
At 8:56 AM -0700 10/9/02, Ed Gerck wrote:
Tamper-resistant hardware is out, second channel with remote source is in.
Trust can be induced this way too, and better. There is no need for
PRNG in plain
view, no seed
[I'm reducing the reply level to 2, for context please see former msg]
Arnold G. Reinhold wrote:
At 8:40 AM -0700 10/11/02, Ed Gerck wrote:
Cloning the cell phone has no effect unless you also have the credentials
to initiate the transaction. The cell phone cannot initiate the authentication
bear wrote:
On Tue, 22 Oct 2002, Ed Gerck wrote:
Short answer: Because the MAC tag is doubled in size.
Longer answer: The birthday paradox says that if the MAC tag has t bits,
only 2^(t/2) queries to the MAC oracle are likely needed in order to discover
two messages with the same
[EMAIL PROTECTED] wrote:
On Tue, 22 Oct 2002, Ed Gerck wrote:
Short answer: Because the MAC tag is doubled in size.
I know, but this is not my question.
;-) your question was Why is RMAC resistant to birthday attacks?
Longer answer: The birthday paradox says that if the MAC tag has
Wei Dai wrote:
On Tue, Oct 22, 2002 at 12:31:47PM -0700, Ed Gerck wrote:
My earlier comment to bear applies here as well -- this attack can be avoided
if only a subset of the MAC tag is used
I can't seem to find your earlier comment. It probably hasn't gone through
the mailing list yet
makes harder
to try a brute force attack.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Sidney Markowitz wrote:
Ed Gerck [EMAIL PROTECTED] said:
That's is not the reason it was devised. The reason is to prevent a birthday
attack for 2^(t/2) tries on a MAC using a t-bit key. Needless to say, it also makes
harder to try a brute force attack.
RMAC was devised for the reason
David Wagner wrote:
Ed Gerck wrote:
(A required property of MACs is providing a uniform distribution of values for a
change in any of the input bits, which makes the above sequence extremely
improbable)
Not so. This is not a required property for a MAC.
(Not all MACs must be PRFs
N we
need in order to have P 0.5, we solve for n and the calculation gives:
N ~ sqrt( 2*ln(2)*2^S ).
Thus, if we consider just two messages, affirmation #1 holds, because
P reduces to 1/S. If we consider n 2 messages, affirmation #2 holds (the
birthday paradox).
Cheers,
Ed Gerck
... pls read this message with the edits below...
missing ^ in exp and the word WITHOUT...still no coffee...
David Wagner wrote:
Ed Gerck wrote:
Wei Dai wrote:
No matter how good the MAC design is, it's internal collision probability
is bounded by the inverse of the size of its internal
.pdf
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
for the
discussion. We can't audit electrons but we can certainly
audit their pattern.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
,
Ed Gerck
Udhay Shankar N wrote:
Ron Rivest is involved, too. Anybody got more info?
http://www.peppercoin.com/peppercoin_is.html
Peppercoin is a new approach to an old challenge: how to make small value
transactionsmicropaymentsfeasible. There is a whole world of digital
content
to limit this behavior. On the other hand, the number
of users who quit after being unlucky is a matter of statistics.
These are apples and speedboats. You ned to have an
implementation barrier to handle #2.
Cheers,
Ed Gerck
David Wagner wrote:
Ed Gerck wrote:
1. If there is no limit
for each
copy. The finer the zone locking resolution, the more effort an attacker needs
to make in order to be able to trade more copies.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe
of AES would satisfy the requirements
-- and compression would NOT help.
Of course, keeping the same key while encrypting the next block would
also satisfy the requirements for the resulting 256-bit ciphertext/plaintext
pair to have a unique solution.[*]
Cheers,
Ed Gerck
[*] But note
for the problem, I submit, is in the
encryption of human-readable text such as English, for which the previous
considerations I read in this list do not apply, and provide a false sense of
strength. For this case, the proposition applies -- when qualified for the
unicity.
Cheers,
Ed Gerck
Arnold G. Reinhold wrote:
At 2:18 PM -0800 2/19/03, Ed Gerck wrote:
The previous considerations hinted at but did not consider that a
plaintext/ciphertext pair is not only a random bit pair.
Also, if you consider plaintext to be random bits you're considering a very
special -- and least
with.
And that's what my paragraph meant.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
and following at
http://crypto.cs.mcgill.ca/~stiglic/Papers/crypto1.ps
(Anton notes that it's not unlikely that there are errors in those notes).
Comments are welcome.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe
in
terms of a real-world model for voting.
This opinion is my own, and is not a statement by any company.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
a secretary to shred the document, but make a copy
first for the files.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
,
reportedly, used this method in Italy to force (and enforce) voter
choices in an otherwise private ballot.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the image sent by the cell phone before the voter leaves the
poll booth.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
easily, by using a
small concealed camera or a cell phone with a camera, obtain a copy of
that receipt and use it to get money for the vote, or keep the job. And
no one would know or be able to trace it.
Cheers,
Ed Gerck
are, respectively:
- India
- Brazil
- US
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Microsoft
weed out these declarations and, thus, help set a higher standard.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
*
(not by construction) in 1997, in what was called intrinsic
certification -- please see www.mcg.org.br/cie.htm
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
is in effect. Also, servers should enable and support
AnonDH by default, unless disabled for performance reasons.
Problem -- SSL AnonDH cannot prevent MITM. The solution is
not to deny the problem and ask who cares about MITM?
Ed Gerck wrote:
BTW, this is NOT the way to make paying for CA certs go
Ben Laurie wrote:
Ed Gerck wrote:
;-) If anyone comes across a way to explain it, that does not require study,
please let me know and I'll post it.
AFAICS, what it suggests, in a very roundabout way, is that you may be
able to verify the binding between a key and some kind of DN
Jeroen van Gelderen wrote:
Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE
bug has any effect on this.
Maybe we're talking about different MSIE bugs, which is not hard to do ;-)
I was referring to the MSIE bug that affects the SSL handshake in HTTPS,
from the context
traffic
is encrypted. So, your 1% figure is also just a part of the picture.
Cheers --/Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Jeroen van Gelderen wrote:
On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote:
Let me summ up my earlier comments: Protection against
eavesdropping without MITM protection is not protection
against eavesdropping.
You are saying that active attacks have the same cost
that such a method should exist.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
It would also outlaw pre-paid cell phones, that are anonymous
if you pay in cash and can be untraceable after a call. Not to
mention proxy servers. On the upside, it would ban spam ;-)
Cheers,
Ed Gerck
Perry E. Metzger wrote:
http://www.freedom-to-tinker.com/archives/000336.html
Quoting
44 matches
Mail list logo
