Cryptography-Digest Digest #671
Cryptography-Digest Digest #671, Volume #10 Fri, 3 Dec 99 06:13:01 EST
Contents:
Re: NP-hard Problems (David A Molnar)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Encrypting short blocks (Markus Peuhkuri)
Re: Encrypting short blocks (Markus Peuhkuri)
how to combine hashes to build a 128-bit key? (Juergen Thumm)
Re: Noise Encryption ("Tim Wood")
Re: brute force versus scalable repeated hashing ("Tim Wood")
Re: brute force versus scalable repeated hashing ("Tim Wood")
Re: more about the random number generator (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: NP-hard Problems
Date: 3 Dec 1999 05:34:33 GMT
Bill Unruh [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED] [EMAIL PROTECTED] (James Pate Williams,
Jr.) writes:
What are some problems that are NP-hard but not NP-complete? I know
Well, it is not known if there are any NP hard problems. But assuming
that say factoring is NP hard, I believe it is not NP complete.
This does not match my understanding of NP hard problems at all. :-(
As in "head explodes at reading previous two posts" out of joint
with what I know. Let me write what I think and hopefully we can resolve
this.
From what I understand :
When we say that a problem P is "NP-hard", we mean that
a) we have a decision problem P defined with respect to some language of
strings L. That is, we have an alphabet $\Sigma$ and a string
$s \in \Sigma^*$ -- a string $s$ consisting of some concatenation
of symbols in the alphabet and of unbounded length -- and we are
asking the question "Is the string s in the language L??"
b) an efficient reduction exists from this problem over L to every other
decision problem P' for an NP-language L'. Let's expand on what
that means :
a "reduction" is a process for rewriting problem questions
for one problem in terms of those for another problem.
In this case, we want something which will let me
take a query for a problem P'
(1) "Is this string s in L' ??"
and `reformat' it such that I can create a new string
and new query like so
(2) "Is this string f(s) in L ??"
(f being some rewriting process or function)
and knowing the answer to query (2) will give me
the answer to query (1).
Put another way - say I know how to solve (2). So I figure
out how to use it to solve (1). What I "do to figure it
out" can be identified with a "reduction."
efficient : means that the reduction takes a polynomial
number of steps in some useful parameter, like the
length of the input.
SO if a problem P is NP-hard, it has this really cool property :
if we can solve P, we can solve all problems in NP.
This is because for every problem in NP, there exists
a reduction which will let us take our method of
solving P and use it to solve anything we want.
Notice at this point that we haven't said anything about whether P is
deciding a language which is actually IN the class NP or not. That's
where NP-complete comes in :
We say a problem is "NP-complete" if it is
a) NP-hard (as above)
b) concerning a language in NP
The NP-complete problem everyone always points to is SATISFIABILITY
: given this logical expression, what values make it true? Karp
showed back in the 70's that you can simulate a universal Turing Machine
by building enough formulae. So SATISFIABILITY is NP-hard.
My confusion at the statement "it is not known if there are any
problems which are NP hard" is that since Karp, lots of ppl have
gone through and shown problems NP-complete and NP-hard in
something like the sense I'm outlining here.
The original question was
"Are there NP-hard problems which are not NP-complete?"
From my understanding, this is equivalent to :
"Are there problems which would let us solve all other
problems in NP if we could do them easily, but are not
themselves in NP ?"
I think so. Now let me try something I'm not so sure of and try to
give an example.
Consider the problem of enumerating *all* bit-strings of length $k$.
There's $2^k$ of them, so it takes exponential time. Also exponential
space. Let's say you have a magic box which takes one step to
enumerate them all and also search them for whatever you happen to want.
Say you want to see if this string $s$ is in an NP-language L. You
just tell your box to write out EVERY string of length $2^|s|$, strike out
anything not in L, and
Cryptography-Digest Digest #672
Cryptography-Digest Digest #672, Volume #10 Fri, 3 Dec 99 11:13:01 EST
Contents:
Re: Encrypting short blocks (Johnny Bravo)
Re: Will ScramDisk recover ? After another round of tests ... YES, it will
recover ("Microsoft Mail Server")
Re: Will ScramDisk recover ? After another round of tests ... YES, it will
recover (Lincoln Yeoh)
Re: Any negative comments about Peekboo how to confirm designer claims ?
(Johnny Bravo)
Re: Any negative comments about Peekboo How to verify that promised algorithms
are included (Johnny Bravo)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Peekboo Ideas? (Lincoln Yeoh)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
How can you tell? (John)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (David A
Molnar)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Encrypting short blocks
Date: Fri, 03 Dec 1999 07:56:16 GMT
On 03 Dec 1999 09:54:04 +0200, Markus Peuhkuri
[EMAIL PROTECTED] wrote:
I'm not sure, but aren't the stream ciphers basicly OTPs where
the "OTP" is generated depending on the key?
A OTP is only a OTP if a random key is used, stream ciphers don't
use random keys. Pseudo-OTP is commonly used to describe them as the
pad is generated pseudo-randomly.
And if I use same
pad for different plaintexts, by guessing/knowing one or some
of plaintexts, all encrypted data can be decrypted without
knowing key?
Correct. If you have the plaintext you can just XOR it with the
ciphertext to recover the key. One of the security requirements of
the OTP is that pad data is not reused under any circumstances.
Best Wishes,
Johnny Bravo
--
From: "Microsoft Mail Server" [EMAIL PROTECTED]
Subject: Re: Will ScramDisk recover ? After another round of tests ... YES, it will
recover
Date: Fri, 3 Dec 1999 08:04:09 -0500
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
the fact that scramdisk retains the essence of boot,fat, data sector
structure is a prime reason it is so durable.
try making two identical container files of moderate size. load some text
files into the svl's for reference points, then swap the boot sector on
each. try swapping the fat structures. very interesting indeed!
--
best regards,
hapticz
X(sign here)
[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]...
|I'm recommending ScramDisk to all the users who have a need to hide and
totally
|secure private computer data as the best product on the market.
|
|After another round of tests, this time with better hex editor, I did find
that
|ScramDisk is very difficult to corrupt [ when not at the beginning of
container
|file ]. My all attempts to porpousedly damage container by editing byte /
bits
|of data proved to be unsuccessful.
|
|In my past test, I did lean to much of my trust on 2 editors for the
changes
|made. The past use editors made changes to the container file in other
places
|than my intention.
|
|After both test made, I'm convinced that ScramDisk will recover [ will NOT
HAVE
|PROBLEM WITH MOUNT OPERATION ] after random bits / bytes are corrupted in
|container file. The above hold true as long as corruption is not in the
system
|part of container.
|
|I would like to apologies to all affected people by my past statements,
that "1
|byte corruption will render container of say 640 MB useless". The statement
is
|not valid to all location of corruption, not valid in generic term.
|
|When the remaining corruption possibility will be removed in the future
versions
|by say [ back up of container system data ], this product will be the best
and
|the safest of all [ file / disk encryption ] products on the market,
|undisputedly.
|--
|Thanks, Richard
|=
|
|Date: Sat, 27 Nov 1999 17:00:47 GMT
|On Thu, 25 Nov 1999 10:02:17 -0500, [EMAIL PROTECTED] wrote:
|Alter 1 byte without increasing container file size.
|After altering, I could not mount container [ provided pass / correct pass
/ has
|not been accepted ].
|
|Dunno, I tried it out, changed a single byte (81 to FF) and I could mount
|it. I'm using 2.02c and blowfish.
|
|I had stored a file inside, and only 9 bytes were changed. Hmm 72 bits
|changed for 6 bits.
|
|What program are you using to change the byte?
|
|As long as you don't alter the first bunch of stuff you should be able to
|mount it.
|
|If you alter the part that happens to be the FAT or directory you may have
|to run scandisk as well to fix things. But
Cryptography-Digest Digest #674
Cryptography-Digest Digest #674, Volume #10 Fri, 3 Dec 99 14:13:02 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: The $10,000.00 contesta (wtshaw)
Re: Encrypting short blocks (wtshaw)
Re: Quantum Computers and PGP et al. (Medical Electronics Lab)
cookies (E-mail)
Re: Is there an analog of Shor's algorithm for elliptic functions? (Medical
Electronics Lab)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: cookies ("karl malbrain")
Re: What part of 'You need the key to know' don't you people get? ("karl malbrain")
Re: cookies (Steve K)
Re: Peekboo Ideas? Oops, problem ... ([EMAIL PROTECTED])
Re: cookies (E-mail)
Re: Peekboo Ideas? Oops, problem ... 2nd ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 03 Dec 1999 12:52:04 GMT
On Fri, 3 Dec 1999 15:17:47 GMT, Tim Tyler [EMAIL PROTECTED] wrote:
What if the coins are all heads-biased (quite likely with real coins),
and the dice are all 1-biased (quite possible if the spots are
drilled indentations)?
One should assume this type of bias from such a mechanical process,
but it is simple to remove the bias from them. For example, you are
using a coin that comes up heads 90% of the time and tails the other
10%. Pair your tosses, throw out any pair that matches. This will
remove the bias from your results.
With the above biased coin:
TT will show up 1 in 100: Discarded
HH will show up 81 times in 100: Discarded
HT will show up 9 times in 100: Kept
TH will show up 9 times in 100: Kept
Giving you a 50/50 distribution of heads and tails. The less
extreme the bias, the closer you get to keeping 50% of your generated
bits. But even an extremely biased source can be used with this
method, if you are willing to accept the slowdowns involved in
distilling unbiased results from the data. This is where computers
come in, if you can use a computer to generate 1000 biased bits a
second and you only kept 1/10 of them it would not be that bad, you
could generate more than 8 million bits in a day.
Your "complications" may dilute the biases - but don't remove them.
I would treat any proposed one-time-pad which used dice or coins
as the basis of its random number generator with some caution - if
I wanted to leak as little information as possible.
It isn't that hard to generate unbiased coin tosses for example, the
trouble comes from generating them at a rate fast enough to be
practical. With coins you would have to make at least 16 tosses per
byte of data. Flipping enough coins to transfer a megabyte is going
to take a while.
Best Wishes,
Johnny Bravo
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 03 Dec 1999 12:03:25 -0600
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Johnny
Bravo) wrote:
..
If they have a claim and offer evidence to support this claim, then
we can define the claim as worth more study.
Surely so.
Making a claim and offering no proof other than the assertion "I'm
right, and you are wrong." is not worth further study. This is
because even if you prove that one claim wrong, they will just throw
out more claims.
Proof in a scientific sense, I suppose. I consider certain things David
Scott says are true by definition. Others, I'm not sure, but keep an open
mind for now.
It is easier to make claims that to support or
disprove them, why should the community be tasked with debunking every
crackpot theory that anyone could ever come up with.
What if is an important strategy to test your position. Science requires
routine reevaluation of positions, not being prejudiced that any taken are
always to be correct; this works on old ideas as well as new.
If you want
people to consider your claims, you need evidence that your claim is
valid.
Yes, but many in science hold a few hypotheses most dearly, but have no
positive or final proof that they are true; cryptography is full of such
things.
The last thing I am going to do is reject
claims if there is reason to believe that they might be true.
Really? I claim you are a murderer. Given that the other people on
this group don't personally know either of us (and have no idea if I
know you personally or not), there is a reason to believe that it
might be true. So now you should prove to the group that you are NOT
a murderer.
I will treat you as an unimformed and ignorant youth who has not respect
for the words you speak, else, you can be prosecuted, and/or sued All
that I can do is yeild that blanket statements concerning your status by
David may be in fact correct. Your position has eroded at your own hand,
Cryptography-Digest Digest #675
Cryptography-Digest Digest #675, Volume #10 Fri, 3 Dec 99 16:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: cookies ("karl malbrain")
Re: Peekboo Ideas? Oops, problem ... 3rd ([EMAIL PROTECTED])
Re: Quantum Computers and PGP et al. (Jim Dunnett)
Re: Elliptic Curve Public-Key Cryptography ("Michael Scott")
Question regarding using RSA BSAFE and BCERT (Sridhar Muppidi)
Re: What part of 'You need the key to know' don't you people get? (James Felling)
Re: Peekboo Ideas? Oops, problem ... 4rd ([EMAIL PROTECTED])
Re: dictionary (fungus)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: Peekboo Ideas? Oops, problem ... 5rd ([EMAIL PROTECTED])
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Why Aren't Virtual Dice Adequate? (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? ("Peter K.
Boucher")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
From: "r.e.s." [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 3 Dec 1999 11:07:27 -0800
"Trevor Jackson, III" [EMAIL PROTECTED] wrote ...
: r.e.s. wrote:
: "Trevor Jackson, III" [EMAIL PROTECTED] wrote ...
: : A simple mechanism is to use a shared secret. Assume that in addition
: : to the (large) message key repository each pair of correspondents is
: : given a unique "signature" value. For purposes of illustration this
: : could be small; 64-256 bits. To send an authenic message one appeads
: : the "signature" to the message, encoding it with the keypad. On
: : receipt of a message the decoder unmasks the "signature" region and
: : compares the result with the secret value. Since the premise of the
: : "signature" is that only the sender and receiver known the valid
: : signature value, and because the signature ciphertext is not reused,
: : the message must have come from one of the two inposession of the
: : secret "signature" value. This approach does not prevent replay
attacks.
:
: In addition to its other functions, doesn't a message key (as defined
: above) accomplish the same thing as the type of "signature" you
describe?
: (It is, after all, a kind of "shared secret", being sent along with the
: enciphered message.)
:
: The message key is created by the sender to be random and unique to each
: transmission, is accessible only to possessors of the primary key, is
: necessary if the decipherment is not to produce garbage, and strengthens
: any stream cipher -- including an OTP -- by helping to ensure that keys
: are really used only once.
:
: What's an "authetic" message key?
A thing is "authentic" if it is what it's claimed to be.
In our context, this means it hasn't been surreptitiously
altered in-transit.
In the scenarios under discussion, a message key is inserted
into the ciphertext in a way that makes it accessible only
to those who know the relevant part of the primary key --
"ciphertext within ciphertext" so to speak.
: The purpose of authenticating a message cannot be addressed by the sender
: synthesizing a value that the receiver cannot calculate.
The receiver *does* calculate it, because some bits of the
primary key -- unknown to the opponent -- serve to do just
that, viz, to extract it from the transmitted ciphertext.
: Thus a message key
: generated by the sender and not already known to the receiver would not
: authenticate a message because the receiver has no way to distinguish
message
: keys selected by the sender from message keys selected by an opponent.
In the scenarios under discussion, an opponent cannot
introduce a message key of his own making because he doesn't
have the key for inserting it into the ciphertext.
--
r.e.s.
[EMAIL PROTECTED]
--
From: "r.e.s." [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 3 Dec 1999 10:00:05 -0800
"Guy Macon" [EMAIL PROTECTED] wrote ...
: [EMAIL PROTECTED] (r.e.s.) wrote:
:
: In practice, though, who would use a "pure OTP" without
: further strengthening? (Even if the OTP is theoretically
: "unbreakable", it seems appropriate to say that any
: OTP *implementation* can, in practice, be relatively
: strong or weak.)
:
: Maybe it's my background as an engineer, but if I was actually
: implementing an OTP (instead of using PGP and just discussing
: OTP as a learning experience), I would go full overkill on the
: randomizer, XORing in everything from the number of microseconds
: between keystrokes to a the digitized output of my local AM
: station, the theory being that if any one of my "random" inputs
: is true random, the OTP will be random. I would then pad my
:
Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #10 Fri, 3 Dec 99 17:13:02 EST
Contents:
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: How can you tell? ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Peekboo Ideas? Question ... ([EMAIL PROTECTED])
Re: cookies ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: cookies ("karl malbrain")
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
From: Eric Lee Green [EMAIL PROTECTED]
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 03 Dec 1999 14:02:07 -0700
"SCOTT19U.ZIP_GUY" wrote:
In article [EMAIL PROTECTED], "Brian Gladman"
[EMAIL PROTECTED] wrote:
Jim Gillogly [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Keith A Monahan wrote:
My concern is that if they DID break one of the algorithms and
didn't tell us(or NIST) about it. I don't know how likely that
is, but it is certainly a possible case.
It wouldn't be _as_ bad as if the NSA broke it, told us about it,
but didn't tell us how. That would still keep me wondering, but
at least we'd know the cipher isn't secure. Even without telling
us how they did it, we might be able to draw some conclusions about
ciphers of that same nature.
If they say they broke it and demonstrate that they can break an
arbitrary challenge, then I agree that's useful information. If
they say they have an attack that reduces a 128-bit keyspace to
a 70-bit keyspace, I'd want to see the attack before making a
decision to eliminate the candidate. Sorry if this appears paranoid,
but we must always remember that NSA has two responsibilities: to
read traffic, and to protect US infrastructure (mainly military).
If you're going to accept their help uncritically, you'd better
know which side of the house is giving it to you. There's no
question that they could provide valuable insight on the candidates;
the only question is how they can convey it credibly.
As others have said, those that distrust NSA are not going to be swayed by
their arguments but for those of us who believe that they are a force for
good in respect of the strength of cryptographic algorithms would consider
what they have to say very seriously. I also believe that they should say
something and I don't see much reason why they should not do so this time
round.
In retrospect, all the ***covert*** actions that NSA took on DES improved
the algorithm and it is not obvious why they would behave differently now.
The US is the most advanced 'information economy' in the world and this
means that the US has more to loose than anyone if AES turns out to be weak.
And this also allows those of us outside the US to trust AES since we are in
a sort of 'Mutually Assured Destruction (MAD) situation' where any NSA
action to bring us down would bring the US down as well.
NSA did reduce the key length of DES from 64 to 56 bits and many thought
that this was so that they could break it but I very much doubt this. Given
the technology available at the time, and their 'volume' cracking needs, I
cannot see that this conclusion stands up under retrospective scrutiny.
This is one fact where your wrong the design of MECL logic boards
was will known at that time. It would be foolish to think they did not build
hardware to conviently break the 56 bit keys.
Although I do not know the answer here, I suspect what it might be. My
guess is that NSA were breaking much poorer algorithms than DES at the time
and desperately needed a way of convincing their targets not to move to DES.
The key length reduction, leaving people to draw the (wrong) conclusions,
was a masterful bit of psychological warfare that did exactly this.
You have got to be joking. Who would belive such nonsense.
As a result of this brilliant deception I suspect that NSA targets went on
using broken algorithms for years even though a great algorithm - DES - was
right in front of their very eyes. And the fact that DES was strong and yet
seemed to outsiders to be weak provided a rare occasion in which the good
guys were able to 'have their cake and eat it' by being able to use DES for
true protection while ensuring that the bad guys were far too suspicious of
it to ever contemplate its use.
You are not even close to reality.
The sad fact is that computer security is many orders of magnitude less
effective than algorithmic security and this will increasingly mean that
there is little point in climbing almost infinitely high
Cryptography-Digest Digest #677
Cryptography-Digest Digest #677, Volume #10 Fri, 3 Dec 99 19:13:01 EST
Contents:
Re: Peekboo Ideas? Question ... (Steve K)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
iaPCBC: confidentiality and integrity in one shot (James Muir)
Re: NSA should do a cryptoanalysis of AES (Shawn Willden)
Re: Why Aren't Virtual Dice Adequate? (Mickey McInnis)
Re: Peekboo Ideas? Question ... (Keith A Monahan)
Re: cookies (SCOTT19U.ZIP_GUY)
Re: Simpson's Paradox and Quantum Entanglement (John R Ramsden)
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: smartcard idea? (Shawn Willden)
Re: Use of two separate 40 bit encryption schemes (Shawn Willden)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
Re: Encrypting short blocks ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Peekboo Ideas? Question ...
Date: Fri, 03 Dec 1999 22:18:43 GMT
On Fri, 03 Dec 1999 16:26:17 -0500, [EMAIL PROTECTED] wrote:
Question
When you are creating password with 'Use Key' is this operation creating THE
SAME password for the same public + private keys selected, time after time ?
Oboy, I know that one!
No. There was some discussion of PRNG implementation during shared
secret generation, in the PB e-list.
Hopefully Tom will have his system back up online pretty soon; until
then, the only living Peekboo expert is incommunicado. Maybe folks
could consolidate their questions hold off 'till Tom shows up on the
network again? Then you could get timely answers, I bet.
:o)
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
--
Crossposted-To: alt.security.pgp
From: Tom McCune [EMAIL PROTECTED]
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 22:29:19 GMT
In article 828lod$kv5$[EMAIL PROTECTED], [EMAIL PROTECTED] (Keith A
Monahan) wrote:
snip
The fact of the matter is that your card can be comprised ANY PLACE, whether
it be locally, over the wire, at the company, at the credit card verification,
etc. If I would place orders online, I would be trying to LIMIT my
susceptibility to attack, and by ensuring a decent encryption package is
in use, I could do that.
Is this more clear?
Thanks Keith,
You give the credit card level of security a higher rating than I do, so that
speaks better of your confidence in the software than if I had made that
statement.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
--
From: James Muir [EMAIL PROTECTED]
Subject: iaPCBC: confidentiality and integrity in one shot
Date: Fri, 03 Dec 1999 22:16:09 GMT
iaPCBC stands for integrity aware plaintext ciphertext block chaining.
It's been proposed as a new mode of operation for block ciphers. It
claims to provide data confidentiality and integrity with one
cryptographic operation. See
http://www.research.att.com/~smb/papers/iapcbc.ps
http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt
for a complete description.
Has anyone analyzed iaPCBC yet? If so, can someone point me to the
analysis?
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Date: Fri, 03 Dec 1999 15:31:34 -0700
From: Shawn Willden [EMAIL PROTECTED]
Subject: Re: NSA should do a cryptoanalysis of AES
"Douglas A. Gwyn" wrote:
This points up a supremely important fact: Real computer security
has to be built in from the ground up, with no loopholes anywhere.
You could probably achieve it with a capability-based architecture
and extremely good security review throughout system design, but
even so, at some level some user will screw up and hand over the
keys to an untrustworthy agent.
Could you explain what you mean by a "capability-based" architecture? I've puzzled
over the term a bit and I can't figure out what you mean by it. Whose capability
and for what? And how does it relate to architecture?
Thanks,
Shawn.
--
From: [EMAIL PROTECTED] (Mickey McInnis)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 3 Dec 1999 22:40:40 GMT
Reply-To: [EMAIL PROTECTED]
snews.austin.ibm.com [EMAIL PROTECTED] 828rmr$[EMAIL PROTECTED]
Organization:
Keywords:
In article 828rmr$[EMAIL
Cryptography-Digest Digest #678
Cryptography-Digest Digest #678, Volume #10 Fri, 3 Dec 99 22:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: ENIGMA verification ([EMAIL PROTECTED])
Re: How can you tell? (Milo Yanker)
Re: Any negative comments about Peekboo free win95/98 message encryptor (David A
Molnar)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tony L.
Svanstrom)
Re: Why Aren't Virtual Dice Adequate? (Scott Nelson)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Vernon Schryver)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: cookies (Yoni Kramel)
Re: NSA should do a cryptoanalysis of AES (John Savard)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us (albert)
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
Crossposted-To: sci.math
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Dec 1999 23:41:26 GMT
In sci.crypt Johnny Bravo [EMAIL PROTECTED] wrote:
: On Fri, 3 Dec 1999 20:02:59 GMT, Tim Tyler [EMAIL PROTECTED] wrote:
[snip removal of bias]
:Other types of deviation from random behaviour are quite possible:
: As are other methods for eliminating various types of bias. You can
: get x unbiased bits from y flips if you distill them enough [...]
It does not look like we are going to reach agreement. I doubt that
you can ever get even one unbiased bit. It does not matter how many
bits you combine, or what techniques you use. Even if you were given a
large stream of bits with entropy 1.0, you would have no way of
verifying the fact.
I fear if the discussion continues in this vein, we will wander from the
relevance to cryptography.
What practical people are concerned with is whether or not it is possible
to build an OTP that's secure enough for the messages they're trying
to convey, against their real-world opponents.
While I don't think this is necessarily an easy target, I would generally
grant that it may be an attainable one, if enough energy is expended
on the problem.
Whether you can get "perfect randomness" in reality is a bit of a
philosophical issue.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Department of Redundancy Department.
--
From: [EMAIL PROTECTED]
Subject: Re: ENIGMA verification
Date: Fri, 03 Dec 1999 23:44:52 GMT
David Hamer [EMAIL PROTECTED] wrote:
One well know example is to be found in the article: "The
Turing Bombe: Was it Enough", Deavours, C.A. Louis
Kruh, Cryptologia XIV(4), pp 331-349, 1990.
Thanks!
I originally asked the question because I could not solve "The Code
Book"'s "Stage 8" cryptogram ... yet when I made up my own cryptograms,
I could solve them easily and quickly. So I was wondering if my
"engine" was doing the Right Thing.
However, it turns out that a few hours after I posted my original query,
I figured out the problem [my simulation was, in fact, correct], and
solved the cryptogram.
[graphical simulators]
Yeah, I found alot of those on the web. Unfortunately, all of them
lacked a certain convenience for my application, even if they were fast
enough. The most useful information I found was, in fact, on your
web-page, filed under "Notes for people who want to make their own
simulators".
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Milo Yanker)
Subject: Re: How can you tell?
Date: Fri, 03 Dec 1999 23:52:33 GMT
John [EMAIL PROTECTED] wrote:
Say you had an encrypter and no source. How would you go about
verifying it?
I wouldn't bother. I would delete it and get one with open source.
--
"Milo Yanker" is actually [EMAIL PROTECTED] (0178 654239).
0123 456789 - Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
--
From: David A Molnar [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: 3 Dec 1999 23:56:01 GMT
In sci.crypt Keith A Monahan [EMAIL PROTECTED] wrote:
David,
Thanks for the response.
No problem. Just wanted to point out that there are various axes of
"trust". and some of them are orthogonal. :-)
problems. I always read companies' privacy/security policies online and
they always talk about SSL encryption and blah blah. But you KNOW alot
of these companies store your credit card info in plaintext on some
networked NT server, or even worse, plaintext on a unix box.
Yeah. This is why SET still seems interesting to me; the idea of doing
credit card transactions (if you _must_ do credit cards) without
storing the card # anywhere is a Good Idea. Too bad that a previous
thread
