Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #14 Wed, 6 Jun 01 09:13:01 EDT Contents: Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen) Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen) Re: Def'n of bijection (Tim Tyler) Re: Bow before your new master (Paul Burke) Re: Def'n of bijection (Tim Tyler) cheksum on keyfile (Gisli Sigurdsson) Re: CTR mode, BICOM, and hiding plaintext length (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding) Re: fast CTR like ciphers? (Tom St Denis) Re: function notation (injection, bijection, etc..) one last time (Tom St Denis) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding) Re: cheksum on keyfile (Mats Kindahl) Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY) Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY) Re: Def'n of bijection (Tim Tyler) Re: Bow before your new master (Robert Strand) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: function notation (injection, bijection, etc..) one last time Date: Wed, 06 Jun 2001 09:44:14 +0200 Tom St Denis wrote: It seems each time I ask people feud over terminology. Let me try again :-) [snip] Please don't misunderstand me but I think that for such questions it is best to consult a textbook on algebra. You would certainly find plenty of them in your local library. The one that I happen to have at hand and I find to be quite good is: L. E. Sieger, Algebra. Springer-Verlag. M. K. Shen -- From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: function notation (injection, bijection, etc..) one last time Date: Wed, 06 Jun 2001 09:57:46 +0200 Mok-Kong Shen wrote: L. E. Sieger, Algebra. Springer-Verlag. Shame, I have often typo. The name is Sigler. M. K. Shen -- From: Tim Tyler [EMAIL PROTECTED] Subject: Re: Def'n of bijection Reply-To: [EMAIL PROTECTED] Date: Wed, 6 Jun 2001 08:13:06 GMT [EMAIL PROTECTED] wrote: : Tim Tyler [EMAIL PROTECTED] writes: : [EMAIL PROTECTED] wrote: :: In other words, you are hoping that false positives are more likely. [...] :: ...some result in that direction is needed for BICOM to provide :: any benefit at all. You don't seem to realize that any such result :: is needed. : : This result seems unnecessary to me because I see it as being : rather obvious. : Ah! It's true, because it's obvious! Why didn't I see that before! Well, it's obvious to *me*. I accept that doesn't necessarily mean that it's obvious to everyone else. Thus my explanations. : This issue is *central* to any claims of increased security for BICOM. Note that it applies to any compression program, not just BICOM. : Therefore, it needs proof, not handwaving. : And the idea doesn't even ``seem'' obvious, because of one fact you : keep ignoring: even if BICOM gives a bijection of binary files to : itself, almost all preimages under BICOM are not in fact plausible : messages. Well, if they were it would be really, really obvious - rather than just obvious. : There is no a priori reason to believe that potential decrypts will be : rich in plausible messages; [...] ...except for the fact that compression makes target files smaller, while increasing the lengths of other files, thus making their density at small output sizes greater. : indeed it seems rather unlikely. Well, you *you*, maybe. : You seem to accept already that an optimal compressor is likely to : make rejecting keys practically impossible. [...] : No I don't, because it's completely false. :-( : It might sometimes prove true, but only by coincidence: if the quantity : of encrypted information turns out to be close to the quantity of key : material, then security may be very high. You can use a three bit key and compress huge files. If all decompressions look like plausible messages it will be hard for an attacker to tell which one was intended. -- __ |im |yler http://rockz.co.uk/ http://alife.co.uk/ http://atoms.org.uk/ -- From: Paul Burke [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Crossposted-To: alt.drugs.pot,sci.electronics.design,sci.electronics.repair,sci.environment Subject: Re: Bow before your new master Date: Wed, 06 Jun 2001 08:23:22 + Mike S. wrote: if you take into account the on-purpose attempts at sounding redneck and inflaming readers. I for one am against discrimination based on neck colour. Smash cervicism! Paul Burke -- From: Tim Tyler [EMAIL PROTECTED] Subject: Re: Def'n of bijection Reply-To: [EMAIL PROTECTED] Date
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #13 Tue, 23 Jan 01 18:13:00 EST
Contents:
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: cryptographic tourism in Russia (Jim)
Re: Some Enigma Questions (Jim)
Re: Some Enigma Questions ("Robert Reynard")
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re:O.T. Corpspeak was (Why Microsoft's Product...) ("Paul Pires")
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Creating a self extracting encrypted exe? ("Ernst")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: Creating a self extracting encrypted exe? ("Paul Pires")
Re: JPEG infidelity for crypto (wtshaw)
KASUMI Analysis? (Was: Re: 3G crypto algorithms) (Kenneth Almquist)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Some Enigma Questions
Date: Tue, 23 Jan 2001 20:02:32 GMT
"David C. Barber" wrote:
... why doesn't the plug board remove, or at least greatly
reduce this vulnerability e.g. A-R-plug board-A?
Because the plugboard accomplishes just a relabeling of the keys.
Q2: How did the plug board disconnect the previous straight through
mapping? Did the process of inserting the plug disconnect the previous
wiring in the same manner that inserting headphone plugs in some stereo
systems automatically disconnects the main speakers?
Yes; the jacks are "normally closed" and were quite common in
telephone switchboards.
Q3: The plugs interchanged pairs of characters, hence there were two plugs
at each end. Were these plugs keyed to prevent improper insertation?
No need to; they're symmetrical.
Q4: Is there still a commercial version of the Enigma for sale that is
essentially the WW II machine?
Not unless somebody is manufacturing them specially for collectors.
Q5: If properly used (e.g. few messages, good mixing of rotor settings, no
obvious rotor settings (e.g. QWE), varying messages to avoid obvious cribs,
having all rotor increment the next rotor at the same position, not sending
the same message in more than one cipher system, changing of rotors more
often than once a war, etc), say along the lines of the German Navy, would
an Enigma today be reasonably secure? Put another way, would it be easily
crackable today by a single person with some cracking tools and a computer,
or would it require a high level team like that assembled during the war?
It depends on who is doing the work. A *lot* more is now known
about cryptanalysis of rotor systems in the classified crypto
community than was known when Bletchley Park was operating.
Q6: How critical is the rotor wiring? While there are some obvious weak
rotors (e.g. a straight through design, a Caesar cipher rotor, or
duplicating the same wiring on the second 13 positions of the rotor), is it
easy or hard to create weak rotors?
This requires a long discussion of cycles, Good diagrams, etc.
which I am not in a position to explain.
Q7: Did the German Navy's creation of a 4th rotor position that included a
rotor that in one position made the machine act like 3 rotor machine result
in a weakened 4th rotor -- even if it hadn't already been compromised
otherwise? Seems to me what the 4th rotor did was simply create a 3 rotor
machine with 26 possible reflecting rotors, instead of the previous 1 fixed
rotor. Right or wrong?
I was under the impression that the additional rotor was a true rotor.
--
From: [EMAIL PROTECTED] (Jim)
Subject: Re: cryptographic tourism in Russia
Reply-To: Jim
Date: Tue, 23 Jan 2001 21:02:25 GMT
On Tue, 23 Jan 2001 10:54:23 +0300, "Vladimir Katalov" [EMAIL PROTECTED]
wrote:
Eric Lee Green wrote in message ...
Hmm... a point there, given that the government there is now run by a
former intelligence officer and that they've a nasty habit of
imprisoning Americans that they think are nosing around in the wrong
place...
A friend of a friend spends time in Russia from time to time (he
supposedly is a school teacher, but has this strange habit of turning
up wherever things are heating up... e.g. Columbia during the worst of
the drug wars, Poland when Solidarity kicked out the Communist
government, Russia during the failed coup, ...). The stories I hear
are pretty bad -- things apparently got pretty lawless for a while,
the old government had virtually collapsed into meaninglessness, and
the new government apparently is overreacting by attempting to clamp
down harshly on all the lawlessness. I'm not sure I'd be adventurous
enough to plan a trip to Russia right now.
Exactly. A trip to Russia might be really dangerous nowadays... I don't
want to scare you, but the situation here looks very sim
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #12 Fri, 25 Aug 00 09:13:00 EDT
Contents:
Re: Serious PGP v5 v6 bug! (Ian Bell)
PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: The DeCSS ruling (Daniel James)
My encryption algorithm ("Slava K.")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: SHA-1 program (cool!) (Mark Wooding)
"Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: How many bits of strength does the ZIP encryption have? (Tim Tyler)
Re: Bytes, octets, chars, and characters (Joona I Palaste)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: "Warn when encrypting to keys with an ADK" ("Michel Bouissou")
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: PGP Vulnerability ("Cheri Mike Jackmin")
UNIX Passwords ("Martin 'SirDystic' Wolters")
From: Ian Bell [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 v6 bug!
Date: Fri, 25 Aug 2000 12:03:00 +0100
In message [EMAIL PROTECTED], Sam Simpson
[EMAIL PROTECTED] writes
Original from Dr R.Anderson, uk-crypto mailing list.
The effect is that GCHQ can create a tampered version of your PGP
public key containing a public key whose corresponding private key is
also known to themselves, and circulate it. People who encrypt
traffic
to you will encrypt it to them too.
Is it possible to put a public key within a public key and for it to
work?
I've tried using PGP6.5.3 to encrypt to a key that had an ADK on it. The
result was that PGP raised an error that I didn't have the ADK's public
key on my keyring and proceeded to just encrypt to the real recipient.
The error message told be that I should ask the recipient for the ADK's
public key.
Therefore it would seem that for GCHQ to exploit the bug, they would
have to add an ADK to Joe Bloggs' key and have to lure people into
downloading the GCHQ public key...
...unless of course, they could put the GCHQ public key _within_ Joe
Bloggs' tampered key and have PGP recognize and use it.
--
Ian BellT U R N P I K E
--
From: "Michel Bouissou" [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 13:20:49 +0200
Well folks,
To be able to diagnose the EXACT behaviour of my PGP 6.5.2 Freeware /
Windows, I made some tests myself which will help understanding how PGP
behaves when encrypting to keys with a forged ADK.
My PGP has the following settings:
- Warning when encrypting to key with an ADK set to ON;
- Display of the ADK column in PGPkeys set to ON.
For this, I imported forged test keys gotten from Ralf's website in the
following way:
1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK was
added
- This key shows up in PGPKeys with the ADK circle being RED, which
immediately identifies this key as containing a forged ADK.
- The properties of the key shows an ADK tab, in which I see the unknown key
(keyID) being an enforced ADK.
== FIRST CONCLUSION: It is immediately visible in PGPkeys that the key
contains an ADK, although PGP doesn't detect that this ADK is a forged one.
2) From the explorer, I encrypted a text file to "Billy Clean's" key and
mine as well.
- As soon as I select "Billy Clean's" key in the recipient key selection
box, I get a dialog box that states:
"The user Billy Clean has a missing Additional Decryption Key". Contact the
owner of the key to obtain the additional decryption key"
- I click on OK then see only my own key and Billy's one in the selected
recipients field.
- I encrypt and all goes well.
- Now I try to decrypt the file. The dialog box shows the file was encrypted
to BILLY and MYSELF, no visible trace of another decryption key.
- I can decrypt the file.
3) Now I import Key-C into my keyring, which is the public key of the
"forger" of Billy's key -- The ADK's public key.
- The "ADK" tab in Billy's public key properties box now shows that his ADK
is "control" (the newly imported key).
4) From the explorer, I encrypt again a text file to "Billy's" key and mine
as well.
- As soon as I select "Billy's" key in the recipient selection box, BOTH
BILLY'S KEY *AND* CONTROL'S one drop into the selected recipients field.
- IT IS THUS VISIBLE THAT "CONTROL" WILL BE ABLE TO DECRYPT THE MESSAGE
- NO SPECIFIC WARNING DIALOG BOX HAS BEEN ISSUED BY PGP although the "Warn
when encrypting to key with an ADK" option was selected.
== SECOND CONCLUSION: The warning option doesn't seem to work at all in
this situation, but it is visible that th
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #10 Tue, 9 Nov 99 15:13:03 EST
Contents:
Re: Can the SETI@home client be protected? (Guy Macon)
OT: dates and sigs[Re: PGP Cracked ?] (Jim Gillogly)
Re: Montgomery vs Sqr Mul -- Specifics (Robert Harley)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: Signals From Intelligent Space Aliens? Forget About It. (SCOTT19U.ZIP_GUY)
Re: What sort of noise should encrypted stuff look like? (Lincoln Yeoh)
Re: Signals From Intelligent Space Aliens? Forget About It. (wtshaw)
Re: How protect HDisk against Customs when entering Great Britain (wtshaw)
Re: What sort of noise should encrypted stuff look like? (wtshaw)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Doug Gwyn
(ISTD/CNS) " [EMAIL PROTECTED])
Re: How protect HDisk against Customs when entering Great Britain (Bill McGonigle)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Self-certified public key.. (Volker Hetzer)
Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
ADVIL (wtshaw)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Medical
Electronics Lab)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 11:21:52 EST
In article jzQV3.4769$[EMAIL PROTECTED], [EMAIL PROTECTED] (ME) wrote:
Some ideas are below
Lyal
Guy Macon wrote in message 8087tr$[EMAIL PROTECTED]...
Here is the situation:
SETI@home [ http://setiathome.ssl.berkeley.edu/ ] is a scientific
experiment that involves millions of Internet-connected computers
in the Search for Extraterrestrial Intelligence (SETI). Participants
run a program that downloads and analyzes radio telescope data from
a server at Berkeley.
Certain people have created unauthorized patches that speed up the
client program. The scientists at the SETI project have asked that
[snip]
Is this an intractable problem?
Yes
However, simple steps increase the difficulty of anyone trying to replace
the client.
I suggest a handshake process based on a challenge-reponse approach.
Start simple solution:
Issue a serial number by client.
Include serial number to track per client performance statistics.
Abberations in performance data can be detected - refuse more test data to
these clients.
End simple solution:
Complex description starts:
- Every client gets a serial number ( As a result, every client will have a
unquie hash result from MD5 or SHA etc).
- The server has a database of serial numbers, and expected hash results
(make the S/N reflect versions to address version control problems)
When the client uploads results, it must request a challenge
1) On receipt of the challenge, it produces a hash value based on the
serialised client and the challenge. This value is unique to the specific
client, and the challenge.
2) The hash and serial number are returned to the server
3) The server calculates the same hash from the serial number, the client
(the S/N version info identifies the client type/version) and the
challenge.
4) If a match, then :
a) accept the data, otherwise dump it.
b) provide more data, otherwise refuse to provide more data.
I suggest step 4 uses a server Public Key to ecnrypt the
challenge/response/serial # data, reducing the potential for spoofing.
This will prove the user has a valid client, and can reduce the potential
for invalid clients to exist.
This also allows statistical performancetracking per client. Clients
exceeding statistiscally expected performance can be considered invalid.
Refuse to supply more test data to these clients.
Not a trivial solution (server-side workload can be high) but the technology
is in use today in a commercial application to validate banking clients are
genuine.
End complex solution.
Start possibly simple solution:
Have a challenge for the fastest client that produces valid outputs on a set
of test data.
Include the fastest client in distrubutions of SET clients.
Offer kudos or a $1000 dollar challenge every month.
The unauthroised client makers may spend more time chasing the $100 than
using their clients to generate results.
End possibly simple solution
Interesting ideas! Does it help to know that the server knows the IP
address (so it can send work units) and the email address (so it can
credit the right person)? Right now those are both created upon
installation of legit or hacked versions. Right now I can download the
client and install it on multiple PCs. Maybe SETI should make the
software so that it only installs from the SETI@home server, serializes
the client, and makes it hard to get results credited to an email
address other than the one entered during
