that takes encrypted cell phone calls
and "forwards" them on a fiber trunk unencrypted for the benefit of
your sister who won't get a better phone... but if she takes the call
on her cell, or on her wireless handset, it's going to be unencrypted
on the air again at her end.
Th
h has become so common is it's
>"public domain" status)?
AES is public infrastructure. It's available for everybody, worldwide,
without copyright or license or patent issues; that was one of the
conditions for even being allowed to enter the AES competi
their livelihoods take. They don't become aware
of crypto when it averts trouble. They become aware of crypto when it
causes trouble.
Bear
-
The Cryptography Mailing List
Unsubscribe by send
ertext that involves less
work than attempting decryption with all possible keys - a property
which, of course, cannot in practice be proven but which is useful to
consider as a lower constraint on key sizes, block sizes, etc.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
On 30 May 2003, Eric Rescorla wrote:
>bear <[EMAIL PROTECTED]> writes:
>There are three possibilities here:
>E(M) || H(E(M)) -> This is radically insecure.
>E(M) || H(M)-> This is still quite dangerous. If the attacker
> can somehow reset
way. And getting away
from that problem is really hard. The problem is, if you really want
to cut past recieved wisdom, you have to have your own wisdom to judge
it by. That means you have to get an idea of what the threats are out
there. And that means not only understanding hundreds of differe
1.
for a good complete description of SHA-1 and a few others, try
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
(warning: link may be outdated).
I don't have pointers to the other two offhand.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
no way for someone to obtain or verify
an email address from a keyserver, but they could still use the email
address to get the key, if it existed, from the keyserver. The
downside would be that you'd run the risk of sending encrypted mail to
someone with no key, but that doesn't cause too much of a problem.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
d like
to have a secure windowing system, but it seems unlikely.
But I think Math is indispensable to crypto, and there
ought to be a secure mathematics library.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
g on, if the legitimate
addressee's DNS record changes because the IP address of that
service actually changes - but with sites like Yahoo, Paypal,
etc, they've got a lot of infrastructure and momentum there.
Those IP addresses don't change on a whim. And those are the
major targets for a DNS spoof.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
just works, you can plug it into an insecure or subverted network
and it'll just work.
At the very least you've got to have a file of keys.
Bear
-
The Cryptography Mailing List
Unsubsc
ntexts it uses to print the reference on the
page.
IOW, if you go to Mallory's search engine, then no matter how many
references you find, they're all coming to you through the same
channel and you have to trust Mallory.
out-of-N secret split, you need to use a curve that
requires three points to establish (such curves include functions
of X^2). And so on...
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
b/webjsp/english/SecureIDE.htm
>
>The idea is simple:
>
>CPU <--> Chip <--> HD
>I quote:
>
>"40-bit DES (US Data Encryption Standard) is adequate for general users"
Interesting. Can these chips be usefully cascaded?
ors for example are unsuitable
for applications such as stream ciphers). When they're not
distinguished, folk tend to use "pseudorandom" as nomenclature
for both.
Bear
-
The Cryptography Mai
On Fri, 22 Aug 2003 [EMAIL PROTECTED] wrote:
>has discussions on maximum information capacity in the physical world.
The event horizon of a black hole is a very special case of
"physical world" -- interesting article though; I read it in
the paper edition.
e-delayed packet relay through many hosts and re-encryption/
redecryption at each step of the way.
That is a model that does not permit realtime communication,
meaning that monitoring may be impossible to escape for
realtime activities suc
outers, and
switches connected to surfola, thereby eliminating the need for
warrant service.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
uot; secure
>coprocessors---more powerful but less secure than their high-assurance
>cousins.
The correct security approach is to never give a remote machine
any data that you don't want an untrusted machine to have. Anything
short of that *will* be cra
wants, somebody else has money or intel to
swap for it. It doesn't take a genius to figure out, it's just going
to happen. Anything an intel service shares with anybody, it's
putting into the network, and it's going to get around to everybody.
perational requirements. But the information has huge economic value
as well as huge personal privacy value. Its inappropriate disclosure
or misuse can destroy lives and livelihoods. It ought to be
considered, and protected, as a target for theft.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
y around
>the physical security, or find a flaw in the application.
You propose to put a key into a physical device and give it
to the public, and expect that they will never recover
the key from it? Seems unwise.
Bear
--
indicates just
>how hard a problem this really is...
Indeed. I think that there ought to be simpler, text-only protocols
for the use of people who don't need to send and recieve live code, so
that they could be effectively protected from live code at the outset
unless they really need it.
ne again and again and again with different
assumptions about what symbols are defined during compilation, before
they can certify it.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
On Wed, 1 Oct 2003, Kevin T. Neely wrote:
>bear allegedly wrote...
>> "Can be relied on to _only_ deliver text" is a valuable and important
>> piece of functionality, and a capability that has been cut out of too
>> many protocols with no replacement in sight.
ITM.
You can have anonymous protocols that aren't open be immune to MITM
And you can have open protocols that aren't anonymous be immune to
MITM. But you can't have both.
Bear
-
On Thu, 2 Oct 2003, Zooko O'Whielacronx wrote:
>
> Bear wrote:
>>
>> DH is an "open" protocol; it doesn't rely on an initial shared
>> secret or a Trusted Authority.
>>
>> There is a simple proof that an open protocol between anonymous
>
ob's key and Bob can't tell Mitch's key from Alice's.
>> > starting with Rivest & Shamir's Interlock Protocol from 1984.
>>
>> Hmmm. I'll go read, and thanks for the pointer.
Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84
ot be applicable to chess? There's nothing to
prevent the two contestants from making "nonce" transmissions twice a
move when it's not their turn.
Bear
-
The Cryptography Mailin
keeping that
credential in terms of risks and benefits. Pseudonymity brings this
aspect of identity credentials to the fore, but it doesn't begin and
end with pseudonymity.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
On Fri, 3 Oct 2003, Benja Fallenstein wrote:
>bear wrote:
>> Why should this not be applicable to chess? There's nothing to
>> prevent the two contestants from making "nonce" transmissions twice a
>> move when it's not their turn.
>
>I.e., yo
e is to continue the game.
T:150 - Mitch sends second half of Alice's move to Mitch
Bob decides on his move.
You could fiddle the intervals, within limits, or allow the players an
"I need more time to think" move, but if they
ntial loss of value tends to
be less for an application crash than for a hosed OS.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
en
to some types of attacks that are very difficult to allow for
in a secure system. Where RSA is used in this mode (for blinding
digital cash, etc) it is used in a very stylized and restricted
way, blinding "tokens" whose
r going to see
of my browsing, email, and anything else I like to keep private is
SSH packets to my home machine, or encrypted X packets running
between the X server on my laptop and X clients on my home machine.
A bit of lag is acceptable. Sending private mail via untrusted
SMTP servers is no
e TCPA is a step toward a technology that
would enable the same kind of struggle over that freedom.
A secure kernel is a kernel that the *owner* of the machine can trust.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
f them are quite good.
You may consider it "living in the woods" to listen to stuff that
isn't the top 20; but I think lots of people will find that the
"woods" is a friendlier and more trustworthy place than a world
full of weasels who want to control their systems.
t get anything I want
without getting things I don't want or risking network
effects that will lead to markets dominated by business
models I don't want to deal with. It makes the buy
decision complicated and fraught with risk.
Bear
--
tent of remote attestataion.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
doesn't really admit purely
technical solutions. What technology can do is shift the problem
around a little, and *try* to shift the problem onto the spammers -
but the successes are always partial and in some way unsatisfactory.
Spam won't stop until spam costs the spammers money.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
protect users against their *own* stupidity?
What we actually need is systems to protect *other* users from their
stupidity.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
like people can't be bothered to keep track of the trust
relationships or reputations within the web.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
orks to
cut out defectors, but couldn't be "autospammed" to cut
out anyone you didn't like?
Sorry; but the fact is no web-of-trust implementation to
date works, or even comes close to working.
Bear
-
lly imposed rarity, and
increasingly people are able to overcome the artificial impositions.
Wouldn't it be a stitch if nations were forced to re-adopt the gold
standard (or adopt the chocolate standard) because all their bills
(and SmartCoins, and RFID tokens
someone who does not think that Alice
and Bob are insane.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
ft" would imply to me that he simply walked into the bank (or
wherever) and took the money (or whatever) at gunpoint, directing
them to charge your account; an image I find more than a little
preposterous. There has to be some kind of fraud or subterfuge
for the proposed cr
or
"simplifies the explanation" for the article, or it gets edited
for length by the publisher, until the explanation given is --
well -- no longer true.
This happens with almost every technology article that attempts
any depth; we should be
the use of POWs
for real-time load balancing, traffic control, etc?
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
t have been fed into the hash function
in the same order as the actual blocks.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
On Wed, 25 Aug 2004, Hal Finney wrote:
>Bear writes:
>> One interesting idea which I came up with and haven't seen a way
>> past yet is to XOR each block with a value computed from its
>> sequence number, then compute the hash function on the blocks in
>> a
Given the same amount
of internal state passed between blocks, the search would be no more
difficult than it is now; for the price of finding k block-length
collisions, the attacker gets 2^k colliding sequences.
So far, your suggestion of passing twice as much internal state
between blocks look
ompletely immune to the attack.
Hal's proposed solution is to double the length of the
internal state, which makes the block collisions much
harder to find and thereby cancels out the advantage
of recombining block collisions.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
p?
Effectively, you're agreeing with him. Good hash functions
*do* evidently cost twice as much work and (at least) twice
as much internal storage as we thought before now to compute.
Your proposal triples the amount of state required through
the process (two one-b
7;s proposal
because we don't have to wait for the next
generation of hash functions to be written.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
On Sun, 29 Aug 2004, John Denker wrote:
>bear wrote:
>>
>>H2(H1) = H1( H1(M) xor H1( TT( M)))
>
>I think that was intended to be something like
>
> H2(M) = H1( H1(M) xor H1( TT( M)))
> ^
Actually, it was intended to take a hash function
a
string taken
>from /dev/random under Linux. They don't care. The german principle is
>that a faculty is always right by definition.
That is inconsistent with the advancement of knowledge. Any
university relying on such a principle has abandoned its duty.
Bear
.
Since there are 1024 distinct ten-bit messages, there
must be at least 1024 distinct nine-bit messages which,
when the reversal is applied, result in these 1024
messages. There are exactly 512 distinct nine-bit
messages. Therefore 512 >= 1
a SHA256 that has its output chopped be
>sufficient?
>
>Any suggestions would be appreciated.
I believe that SHA256 with its output cut to 128 bits will be
effective. The simplest construction is to just throw away
half th
top line (since all pairs collide in the top line),
>so you have a collision for the whole hash (same H1,H2).
The birthday paradox does not apply in this case because H1 is fixed.
The above construction is in fact secure against the Joux attack as
stated. 2^80 work will find, on average, one colli
ever meaninglessly, while their customers still
get lots of UCE. Indeed, there are a lot of systems out there
that don't have any published threat model. These are failures
of protocol design, though not necessarily failures of
marketability. But to the extent that they allow bypassing
filters, t
those which cannot be linked to any
other no matter how hard someone tries.
We can expect the public to fail to grasp the distinction, but
on this list "anonymous" is a very strong claim. Anonymity is
*HARD* to do, not something that results from failing to check
a credential.
?
whichever it is, as you point out there are other and more secure
modes available for using 3DES if you have a fat pipe to encrypt.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
rrectly, and
even if we developed notation and semantic models that took these
issues into account, it would be difficult to get them to run
correctly on desktop machines.
> - Use specialized hardware, designed not to leak side-channel
> information.
I think the easies
those keys. Making key distribution
require human attention/intervention. This is treating key distribution
seriously, and possibly for the first time in the modern incarnation of the
industry.
Bear
--
But some systems have
proofs that someone who has access to the entire output of the PRNG so
far has no strategy better than random guessing for determining the
next and subsequent outputs, and that may be "random" enough for your
bosses.)
machine can be built just because the way they
already know to build one (Shor's algorithm, which requires n qbits)
won't work. Given that our knowledge of QC is nascent, our
ignorance of QC's practical limits is likely staggering, and
caution is to be advised.
s. (Note that DVD-ROMs are better).
That gives you a little over 100 years (read, "all you're likely
to need, barring catastrophic medical advances,") of a very
secure low-bandwidth channel.
Of course, the obvious application for this OTP material,
other than text messaging
On Thu, 26 Jan 2006, Adam Fields wrote:
>On Thu, Jan 26, 2006 at 06:09:52PM -0800, bear wrote:
>[...]
>> Of course, the obvious application for this OTP material,
>> other than text messaging itself, is to use it for key
>> distribution.
>
>Perhaps I missed somethi
blem with that disincentive is that I need to sink the money for
>each certificate I have. Clearly this doesn't scale at all well.
>
Um, if it's anonymous and unlinkable, how many certificates do you
need? I should think the answer would b
en that both ciphers are sufficiently strong that their strength
has nothing to do with the mimimum effort required to attack their
application.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
nbetween the
channels that were assigned whole numbers in TV tuning. So you could
pick up some cell traffic if you tuned, for example, to UHF TV
"channel" 78.44. But not if you tuned to channel 78 or channel 79.
Bear
^H^H^H^H^H^H^H^H^H^H^H^H see which
interpretation of the statute best serves justice.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
s nor revoke
transferred keys.
There is no root key whose further key-signing is controlled by any
process related to security, nor is keysigning halted or signed keys
revoked in the case of users who have perpetrated or permitted known
security abuses.
It should therefore be no surprise that SSL
73 matches
Mail list logo
