Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #14 Thu, 31 May 01 14:13:01 EDT Contents: Re: National Security Nightmare? (Sam Simpson) Re: Question about credit card number (Mark Borgerding) Re: Card Games (Yoad Lustig) Re: differential oddity (Niels Ferguson) Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED]) Re: Question about credit card number (John Joseph Trammell) Re: Medical data confidentiality on network comms (Niels Ferguson) Re: Quantum Computers with relation to factoring and BBS (Bob Silverman) Re: Question about credit card number (Darren New) Re: And the FBI, too (Re: National Security Nightmare?) (Bob Silverman) Re: Euroean commision will recommend all citizens to use encryption in (Thomas J. Boschloo) Re: Euroean commision will recommend all citizens to use encryption in (Thomas J. Boschloo) Re: Certicom's ECCp-109 Challenge (call for users) (Stefan Katzenbeisser) Re: Fractionated Morse - Help (BenZen) Re: Was there ever a CRM-114 Discriminator? (Sam Yorko) Diffusion limits in block ciphers ([EMAIL PROTECTED]) Re: Definition of 'key' (John Savard) crypt education (Matt) Re: Good crypto or just good enough? (Joseph Ashwood) From: Sam Simpson [EMAIL PROTECTED] Subject: Re: National Security Nightmare? Date: Thu, 31 May 2001 17:06:08 +0100 Mok-Kong Shen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Sam Simpson wrote: Douglas A. Gwyn [EMAIL PROTECTED] wrote: You shouldn't believe much of what you read in the newspaper. The NSA charter was declassified years ago. They emphatically do not have a charter to spy on US citizens; to the contrary they are forbidden by law to do so except under certain extraordinary circumstances; there are various watchdog mechanisms and mandatory awareness training in a serious attempt to conform to that law. True, in the same way that the UK GCHQ equivalent of doesn't spy on UK citizensIt gets other countries security establishments to do their dirty work. That's not unnatural, after all. No, but it's deceitful: The law of the country says that we can monitor Mr x's communications, so we'll ask a foreign to spy on a UK citizen residing in the UK to circumvent this law. Regards, -- Sam Simpson http://www.scramdisk.clara.net/ -- From: [EMAIL PROTECTED] (Mark Borgerding) Subject: Re: Question about credit card number Date: 31 May 2001 09:13:50 -0700 Chenghuai Lu [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Most of the commecial websites keep the customers' credit card numbers in their database. You sparked a thought in me. I imagine most web credit card systems store the number in a database that is accessible to the webserver. Instead, wouldn't it be better to give the webserver very limited capability to use the credit card. i.e. After the user has added their credit card, it gets wisked away to a more secure machine than the webserver. This machine can only communicate to the webserver through a well-defined interface. The webserver/database would store only a memento (last 4,hash,etc) to identify the specific card so that the user can select it. The important thing is that after the credit card is initially entered, even root on the webserver / database server cannot access the actual card number. The only thing it would be able to do is to purchase individual items -- much easier to detect and defeat than the actual number being stolen. So the credit card server would only need to perform the following functions: - receive new numbers - make purchases, given a memento from the webserver/database server A machine that does only those functions should be much easier to lock down and make secure than a machine that also needs to act as a webserver. Any comments? -- From: Yoad Lustig [EMAIL PROTECTED] Subject: Re: Card Games Date: Thu, 31 May 2001 19:41:40 +0300 Hi, I'm not sure whether your question was theoretical or practical. If it was theoretical here's a good place to start http://www.wisdom.weizmann.ac.il/~oded/pp.html Nigel Smart [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi All, I am sure I once saw something about card games in a cryptographic setting. But I cannot remember where. Basically I would like to know is it possible for four people to shuffle and deal 13 cards to each other without either party knowing the cards of the other party and allowing each party to know that the cards have been dealt fairly Basically this is some kind of multi-party computation but with a shuffle. Any pointers to the literature would be most helpful. Yours Nigel -- Dr Nigel P. Smart | Phone: +44 (0)117 954 5163 Computer Science Department, | Fax: +44 (0)117 954 5208 Woodland Road, | Email: [EMAIL
Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #13 Wed, 17 Jan 01 16:13:01 EST
Contents:
Why Microsoft's Product Activation Stinks (zapzing)
Re: Q: split keys (Mike Rosing)
Re: rubik's cube (Tony L. Svanstrom)
Re: Why Microsoft's Product Activation Stinks ("Mysterion")
Re: Why Microsoft's Product Activation Stinks ("Kristopher Johnson")
Re: RC5 on 16 word? (Simon Johnson)
Re: RC5 on 16 word? ("N. Weicher")
NTRU Public Key System as a knapsack cryptosystem (John Bailey)
Re: RC5 on 16 word? (Tom St Denis)
Re: SAC question (Tom St Denis)
Re: future trends in asymmetric cryptography (Dido Sevilla)
Re: A Small Challnge (fred weigel)
Re: block algorithm on variable length without padding? ("Joseph Ashwood")
Re: RC5 on 16 word? ("Joseph Ashwood")
From: zapzing [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Why Microsoft's Product Activation Stinks
Date: Wed, 17 Jan 2001 18:23:52 GMT
Upcoming versions of windows may have, I
read, something called "product activation".
This means that you must call up microsoft
so that the OS can have permission to run.
I have a few questions about this. First of
all, under what conditions will MS
*refuse* to activate the product. It seems
to me that if they never refuse activation,
then putting in product activation code is
pretty useless. And if they do, they may
deny legitimate users who reconfigure their
systems frequently.
Also, what about the possibility of a major
computer virus that requires many machines
to restore. This would of course require
that the OS be reactivated, but in that case
the product reactivation lines could be
jammed. This would make me think about it
very carefully before I bought an OS that
included product reactivation code.
I understand MS's desire to protect their
intellectual property, but please try to think
of something that will not cause the collapse
of civilization.
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
--
From: Mike Rosing [EMAIL PROTECTED]
Subject: Re: Q: split keys
Date: Wed, 17 Jan 2001 12:24:57 -0600
Andy Resnick wrote:
As many of you may know, Newsweek had an article about the history of
cryptograpy, and had (for me, anyways) an unusually clear explanation of
how public/private key encryption works. I'm no expert. My question
is, does the use of two keys imply that there is more than one
transformation to properly decode an encrypted signal? That is, I
recieve an signal encoded with (for example) PGP. Now, I'm too lazy to
get the public key but I have infinite computing power (hey, this is a
thought experiment!). It seems that I will find *two* keys to decrypt
the message, and I have a hunch that they will be based on the two
primes that factor a large number.
Am I somewhat on the right track here?
Not quite. There are really 2 levels of encryption in real world settings
like PGP. The outer level uses public keys. The inner level uses regular
symmetric key, like IDEA or the new AES. The outer level encrypts the
session key and the session key encrypts the message (inner level).
For you to decrypt a message you only need your own private key. Other
people have to find your public key to send you a message. They use
a session key (some random garbage) to encrypt the message, then use
your public key to encrypt the session key.
The outer level uses "hard" problems to hide the inner level key. The
inner level uses non-linear bit banging, and has nothing to do with
factoring. One could in principle solve a set of equations to find a
session key, but it would probably take longer than a brute force trial
and error method.
Patience, persistence, truth,
Dr. mike
--
Crossposted-To: comp.security.pgp.discuss
Subject: Re: rubik's cube
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 17 Jan 2001 18:35:51 GMT
[Followup-To: sci.crypt]
Gateway #3 [EMAIL PROTECTED] wrote:
Do you know of works that consider encryption based on the Rubik's Cube ?
(I mean in terms of evaluation). I am by no means a crypto expert
This doesn't really belong in comp.security.pgp.discuss, try sci.crypt
instead.
but i would like to know the state of the art regarding this technique of
permutation as an encrypting device:
* broken
* weak
* probably weak
* unknown
Of course, cube size and key size may influence it.
It APPEARS to be interesting, given the extraordinary number of combos you
can generate with SHORT KEYS. Besides, it's also very FAST, much faster than
DES-like algos for instance.
But all this may be deceitful if papers report that it's easy to break.
And intuitively, i think that cryptanalysis is harder when you "move from 2d
to 3d"
(operations are perfomed accross 3 axes, wh
Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #12 Sat, 19 Aug 00 00:13:01 EDT
Contents:
Re: How strong is this algorithm? ("Scott Fluhrer")
Secure VoIP IM ("Mike")
Re: blowfish problem (Dennis Ritchie)
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
From: "Scott Fluhrer" [EMAIL PROTECTED]
Subject: Re: How strong is this algorithm?
Date: Fri, 18 Aug 2000 18:54:25 -0700
Jeff Davies [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I have an idea for a non-profit electronic cash system (a bank)
for which I have devised I think a new algorithm.
Why? What's wrong with 3DES, Serpent or AES? Seriously: the banking
industry currently uses (I believe) 3DES, Serpent was designed by someone in
the banking industry (Ross Anderson), and AES (which might turn out to be
Serpent) is considered "good enough" for the US government uses. Why should
I trust my money to a bank that uses home-brew crypto?
Can anyone tell me how to evaluate how strong this is??
4. The encryption technology is as follows:
Note I have called this proposal "256 bit" however, I think it is
stronger than traditional
256 bit methods. Instead of changing a pattern of bits larger than a
character into an
equivalent, random values scramble the message bits into a random
packet 128 times larger.
Electrocash will use Symmetric keys. Traditionally, asymmetric keys
are used to prevent possibility of
compromisation of the person's key from the server, where a third
party could pretend to
be the person. However, Clients are at the time of writing, far more
vulnerable than
the server. As a result, the private key is probably more likely to
be lost than public key.
So, as asymmetric are less strong per bit (2300 bit asymmetric is
equivalent
to about 256 bit symmetric in strength), multiple symmetric keys
will be used with
Electrocash.
To be pedantic, the relative strength of an asymmetric system "per bit"
varies greatly with the exact system. ECC keys that are believed to have 256
bit strength are considerably smaller than 2300 bits...
Not that the "per bit" strength is a particularly useful notion...
The key works as follows: for each bit in the packet (encrypted
packet length is 256 bits)
there is a 16 bit word specifying it's position in a larger word
where unmapped bits have
random values. At the outset, the upper two bits of the 16 bit word
will not be used,
as a single udp packet of around (max) 1500 bytes is standard on
networks sent.
Naturally, therefore, the encrypted bit position can be one of 4096
(from it's original
position within 256 bits).
Each key has 256 off 16 bit words (totalling 512 bytes) positioning
the encrypted bits
within the larger packet. The values in the key are originally
generated by Electrocash
Server using a psuedo-random binary sequence generator (cannot
repeat within 256 values).
The unencrypted part of the packet gives a 16 bit integer choosing
the key from
the 2048 supplied every month in a 1 megabyte smartcard (or
similar).
Each key is used for only one transaction (this might be modified if
it proves unworkable).
If each key is used to transmit a single message, it looks safe, if rather
crude. If it is used to transmit multiple messages (and that includes
multiple messages from the same "transaction"), then it looks easy enough to
break (or at least, give the attacker enough idea about the messages to know
which bits to manipulate). And, not putting in any sort of MAC allows bored
attackers to have fun flipping random bits, and seeing what happens...
Per user, 2048 keys are created per month, and distributed by
snailmail on a smartcard or similar.
So, if someone manages to grab the smartcode out of the mailbox, he will be
able to impersonate you, and withdraw all your funds from the bank?
Oh, and what do you do if someone's a bit busy, and needs to exchange more
than 2048 messages with the bank in a month?
There is no certification mechanism, as this can be bruteforced. you
can't rely on client's being secure.
The encryption algorithm is created outside the US, so that it is
not subject to US export restrictions.
As no data is stored in encrypted form, this should comply with UK
"Rights of the People Bill".
When Client talks to server, first unencrypted message specifies
account number and encryption key to use
from the 2048 sent. There is never a need for personal accounts for
the same encryption key
to be used twice. So when a key is used, it is discarded.
This makes bruteforcing impossible. The client used might be
compromised. In the case of a compromised client
money lost is at the account holder's own risk.
Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #10 Mon, 1 Nov 99 07:13:04 EST Contents: Cryptography FAQ (06/10: Public Key Cryptography) ([EMAIL PROTECTED]) Cryptography FAQ (07/10: Digital Signatures) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (06/10: Public Key Cryptography) Date: 1 Nov 1999 11:28:42 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part06 Last-modified: 94/06/07 This is the sixth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents: 6.1. What is public-key cryptography? 6.2. How does public-key cryptography solve cryptography's Catch-22? 6.3. What is the role of the `trapdoor function' in public key schemes? 6.4. What is the role of the `session key' in public key schemes? 6.5. What's RSA? 6.6. Is RSA secure? 6.7. What's the difference between the RSA and Diffie-Hellman schemes? 6.8. What is `authentication' and the `key distribution problem'? 6.9. How fast can people factor numbers? 6.10. What about other public-key cryptosystems? 6.11. What is the `RSA Factoring Challenge?' 6.1. What is public-key cryptography? In a classic cryptosystem, we have encryption functions E_K and decryption functions D_K such that D_K(E_K(P)) = P for any plaintext P. In a public-key cryptosystem, E_K can be easily computed from some ``public key'' X which in turn is computed from K. X is published, so that anyone can encrypt messages. If decryption D_K cannot be easily computed from public key X without knowledge of private key K, but readily with knowledge of K, then only the person who generated K can decrypt messages. That's the essence of public-key cryptography, introduced by Diffie and Hellman in 1976. This document describes only the rudiments of public key cryptography. There is an extensive literature on security models for public-key cryptography, applications of public-key cryptography, other applications of the mathematical technology behind public-key cryptography, and so on; consult the references at the end for more refined and thorough presentations. 6.2. How does public-key cryptography solve cryptography's Catch-22? In a classic cryptosystem, if you want your friends to be able to send secret messages to you, you have to make sure nobody other than them sees the key K. In a public-key cryptosystem, you just publish X, and you don't have to worry about spies. Hence public key cryptography `solves' one of the most vexing problems of all prior cryptography: the necessity of establishing a secure channel for the exchange of the key. To establish a secure channel one uses cryptography, but private key cryptography requires a secure channel! In resolving the dilemma, public key cryptography has been considered by many to be a `revolutionary technology,' representing a breakthrough that makes routine communication encryption practical and potentially ubiquitous. 6.3. What is the role of the `trapdoor function' in public key schemes? Intrinsic to public key cryptography is a `trapdoor function' D_K with the properties that computation in one direction (encryption, E_K) is easy and in the other is virtually impossible (attack, determining P from encryption E_K(P) and public key X). Furthermore, it has the special property that the reversal of the computation (decryption, D_K) is again tractable if the private key K is known. 6.4. What is the role of the `session key' in public key schemes? In virtually all public key systems, the encryption and decryption times are very lengthy compared to other block-oriented algorithms such as DES for equivalent data sizes. Therefore in most implementations of public-key systems, a temporary, random `session key' of much smaller length than the message is generated for each message and alone encrypted by the public key algorithm. The message is actually encrypted using a faster private key algorithm with the session key. At the receiver side, the session key is decrypted using the public-key algorithms and the recovered `plaintext' key is used to decrypt the message. The session key approach blurs the distinction between `keys' and `messages' -- in the scheme, the message includes the key, and the key itself is treated as an encryptable `message
Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #9 Thu, 29 Apr 99 22:13:02 EDT
Contents:
Re: Factoring breakthrough? (John Savard)
NEC breakbrough in Quantum computing (Stanley Chow)
Re: Arab Terrorists Must Bomb Moscow Belgrade KKKommunists ("Lewis Sellers")
Re: Double Encryption is Patented! (from talk.politics.crypto) (Peter Gutmann)
Re: Weakness Found in Alternative Signature Format (Jim Gillogly)
Re: Factoring breakthrough? (John Savard)
Re: Factoring breakthrough? ("Michael Scott")
Re: observation on superencryption ([EMAIL PROTECTED])
Re: break this code (Jim Gillogly)
Re: Weakness Found in Alternative Signature Format ([EMAIL PROTECTED])
Re: Common Passowrds (Nathan Christiansen)
Free Steganographic program ([EMAIL PROTECTED])
Re: Random Number Generator announced by Intel ("Trevor Jackson, III")
Re: Weakness Found in Alternative Signature Format (David A Molnar)
Re: Common Passowrds (Boris Kazak)
Advanced Workshop: USENIX Smartcard Technology, May 10-11, Chicago (Jennifer Radtke)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Factoring breakthrough?
Date: Thu, 29 Apr 1999 20:33:37 GMT
lcs Mixmaster Remailer [EMAIL PROTECTED] wrote, in part:
Rumor has it Adi Shamir will announce factoring breakthrough soon.
Increasing efficiency by orders of magnitude and breaking keys 100-200
bits longer than current state of the art.
Anybody confirm/deny?
I can't help you, I haven't even heard the rumour. If there *is* any truth
to the rumour, we hope that its reaching more ears won't lead to Dr. Shamir
either disappearing or being pressured...
although the spooks in this area are actually sophisticated enough to know
the futility of such things.
Maybe the rumor will protect him, since it will start people using longer
keys or something (and if something happened to him, more so) and losing
the ability to break RSA, not having it become insecure (since they don't
use it much) would worry the "spooks" - even, say of less enlightened
countries than the much-unjustly-maligned U.S..
Of course, most rumors turn out to be some bored fellow's idea of a joke...
John Savard ( teneerf- )
http://members.xoom.com/quadibloc/index.html
--
Date: Thu, 29 Apr 1999 12:40:11 -0400
From: Stanley Chow [EMAIL PROTECTED]
Subject: NEC breakbrough in Quantum computing
According to The Register:
http://www.theregister.co.uk/990429-16.html
NEC has some new QuBit scheme on semiconductor (with buzzword: Cooper
pair
box, super conducting electrode, Josephson Junction2).
Anyone know any details?
--
Stanley Chow phone: (613) 271-9446 Fax: (613) 271-9447
VP Engineeringemail: [EMAIL PROTECTED]
Fallingbrook Technologies Inc.
--
From: "Lewis Sellers" [EMAIL PROTECTED]
Crossposted-To: sci.med.transcription,sci.space.policy,sci.electronics.repair
Subject: Re: Arab Terrorists Must Bomb Moscow Belgrade KKKommunists
Date: Thu, 29 Apr 1999 21:03:58 GMT
[EMAIL PROTECTED] wrote in message
7f0i68$s4m$[EMAIL PROTECTED]...
Why aren't the wimpy Syrian, Iraqi, Libyan, Afghani, etc., pussy terrorist
dogs bombing Moscow and Belgrade???!!! Where are the oil-rich,
Rolls-Royce-riding Arab Muslims from Kuwait, Saudi Arabia after American
and
other NATO soldiers died saving their greedy asses???!!!
It's obvious that the KKKommunist-Nazis in Russia and Serbia are the real
Great Satans killing, raping, and pillaging Albanian Muslims, but where is
the shock and outrage from the Arab Muslims???!!!
Actually the serb leaders are Marxists, not Communists.
--
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Double Encryption is Patented! (from talk.politics.crypto)
Date: 29 Apr 1999 20:45:58 GMT
[EMAIL PROTECTED] (John Savard) writes:
[EMAIL PROTECTED] (John Savard) wrote, in part:
[EMAIL PROTECTED] (John Savard) wrote, in part:
Oh, my. This patent sounds like it covers a technique I was planning to
use, although, as someone else noted, it isn't double encryption.
I should have mentioned that it's U.S. patent 5673319, and it's from 1997.
But it was filed in February 1995, so my first posting of what may be a
similar idea on September 11, 1996 won't cause the patent any problems. Ah,
if only I had gotten on the Internet sooner...
Actually there's prior art from 1993, this is the no-IV encryption I used for
disk sector encryption in SFS, http://www.cs.auckland.ac.nz/~pgut001/sfs/.
The method was designed by Colin Plumb, for speed reasons it doesn't use two
passes of CBC but one pass of an SHA-1 style scrambler which produces a 160-
bit plaintext-dependant IV, and a second pass which does the actual
encryption. IANAL, and my eyes were starting to hurt reading that scanned
text, but apart from the use of a (slow) MAC vs a (fast) simple checksum,
the t
