Cryptography-Digest Digest #185
Cryptography-Digest Digest #185, Volume #14 Thu, 19 Apr 01 18:13:01 EDT
Contents:
Re: First cipher ("M.S. Bob")
Re: A practical idea to reinforce passwords ("Tom St Denis")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Reusing A One Time Pad (James Felling)
Re: Current best complexity for factoring? (Terry Boon)
Re: "I do not feel secure using your program any more." (James Felling)
Re: "I do not feel secure using your program any more." ("Tom St Denis")
Re: Basic AES question (SCOTT19U.ZIP_GUY)
Re: Any unbroken knapsack cryptosystem? ("Joseph Ashwood")
Re: OTP breaking strategy (newbie)
Re: "UNCOBER" = Universal Code Breaker (James Felling)
Re: OTP breaking strategy ("Tom St Denis")
Re: OTP breaking strategy ("Tom St Denis")
Re: OTP breaking strategy (Joe H Acker)
Re: Current best complexity for factoring? (SCOTT19U.ZIP_GUY)
From: "M.S. Bob" [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 21:39:36 +0100
[EMAIL PROTECTED] wrote:
Here's my first attempt at a block cipher. Please critique
and explain WHY as well as where I'm going wrong.
1.) Feistel network, blocklength 64 bits, 128-bit key, 16 rounds
Short (pointers to more) reading list:
Memo to the Amateur Cipher Designer
http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
Self-Study Course in Block Cipher Cryptanalysis
http://www.counterpane.com/self-study.html
Memo to the Amateur Cipher Designer
by Bruce Schneier (October 15, 1998)
Congratulations. You've just invented this great new cipher, and you
want to do something with it. You're new in the field; no one's heard of
you, and you don't have any credentials as a
cryptanalyst. You want to get well-known cryptographers to look at your
work. What can you do?
Unfortunately, you have a tough road ahead of you. I see about two new
cipher designs from amateur cryptographers every week. The odds of any
of these ciphers being secure are slim. The odds
of any of them being both secure and efficient are negligible. The odds
of any of them being worth actual money are virtually non-existent.
Anyone, from the most clueless amateur to the best cryptographer, can
create an algorithm that he himself can't break. It's not even hard.
What is hard is creating an algorithm that no one else
can break, even after years of analysis. And the only way to prove that
is to subject the algorithm to years of analysis by the best
cryptographers around.
"The best cryptographers around" break a lot of ciphers. The academic
literature is littered with the carcasses of ciphers broken by their
analyses. But they're a busy bunch; they don't have time
to break everything. How do they decide what to look at?
Ideally, cryptographers should only look at ciphers that have a
reasonable chance of being secure. And since anyone can create a cipher
that he believes to be secure, this means that
cryptographers should only look at ciphers created by people whose
opinions are worth something. No one is impressed if a random person
creates an cipher he can't break; but if one of the
world's best cryptographers creates an cipher he can't break, now that's
worth looking at.
The real world isn't that tidy. Cryptographers look at algorithms that
are either interesting or are likely to yield publishable results. This
means that they are going to look at algorithms by
respected cryptographers, algorithms fielded in large public systems
(e.g., cellular phones, pay-TV decoders, Microsoft products), and
algorithms that are published in the academic literature.
Algorithms posted to Internet newsgroups by unknowns won't get a second
glance. Neither will patented but unpublished algorithms, or proprietary
algorithms embedded in obscure products.
It's hard to get a cryptographic algorithm published. Most conferences
and workshops won't accept designs from unknowns and without extensive
analysis. This may seem unfair: unknowns
can't get their ciphers published because they are unknowns, and hence
no one will ever see their work. In reality, if the only "work" someone
ever does is in design, then it's probably not worth
publishing. Unknowns can become knowns by publishing cryptanalyses of
existing ciphers; most conferences accept these papers.
When I started writing _Applied Cryptography_, I heard the maxim that
the only good algorithm designers were people who spent years analyzing
existing designs. The maxim made sense, and I
believed it. Over the years, as I spend more time doing design and
analysis, the truth of the maxim has gotten stronger and stronger. My
work on the Twofish design has made me believe this
even more strongly. The cipher's strength is not in its design; anyone
could design something like that. The strength is in its analysis. We
spent o
Cryptography-Digest Digest #185
Cryptography-Digest Digest #185, Volume #13 Sun, 19 Nov 00 06:13:01 EST
Contents:
Re: voting through pgp (long) ("John A. Malley")
Re: XOR Software Utility (freeware) available from Ciphile Software (Anthony Stephen
Szopa)
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Anthony
Stephen Szopa)
Re: vote buying... (Paul Rubin)
QUESTION on openssl 0.95a!! ("Verd")
Re: XOR: A Very useful and important utility to have (Guy Macon)
Re: Criteria for Simple Substitutions? ("news.free.fr")
Re: DES advice (ArchimeDES)
Re: Cryptogram Newsletter is off the wall? (David Crick)
Mode of operation to maintain input size with block ciphers? ("Benny Nissen")
AES/Rijndael performance on Pentium 4? (David Crick)
From: "John A. Malley" [EMAIL PROTECTED]
Subject: Re: voting through pgp (long)
Date: Sat, 18 Nov 2000 22:26:15 -0800
Benjamin Goldberg wrote:
[snip]
(Vague hunch this Doppleganger attack can be transformed into a
decidability problem of some kind, and that the decidability problem
is undecidable - there is no algorithm for it.)
Hmm, suppose we have an AI, and a human, and we can have a text only
conversation with each. Further assume that the AI is advanced enough
that a human being can't tell which is which better than 50% of the
time. Is it possible to create another AI which *can* tell which is
which?
An interesting problem, but there may be another (simpler)
representation of the man-in-the-middle "Doppleganger" attack by a rogue
application on the voter's machine and the ability of the vote taker to
discern the presence of a "Doppleganger."
The citizen voter will issue only a limited number of strings (vote
choices) to the vote taker. There's an application that interacts with
the voter with an interface, and the application interacts with the vote
taker with another interface (client-server model here.)
This application need not be complicated (such that the Turing Test
comes into play here) - it could just be a finite state machine (regular
languages) or a push-down automaton (context free languages). Every
regular language may be recognized by a finite state machine. Every
context free language may be recognized by a pushdown automaton. These
are in themselves decidable languages (sets of strings.)
Assume the application for remote voting lets the voter choose one out
of n possible candidates, applies encryption and authentication
protocols to that choice and sends the protected result to the vote
collector. The application always halts for each of the n possible
choices.
A trojan horse application does almost exactly the same thing. The
application lets the voter choose one out of n possible candidates but
always substitutes a different selection in lieu of the voter's
selection, applies encryption and authentication protocols to that
substituted choice and sends the protected result to the vote collector.
The trojan horse application halts for each of the n possible choices.
The vote collector decrypts the choice from the voter and authenticates
it. The voter checks out as true and the protocols show the choice was
not altered between the output of the application and the vote
collector. But in the case of the trojan application this choice is not
the choice actually made by the voter.
Is there an algorithm to decide if a single choice that was properly
encrypted and authenticated came only from the unadulterated client
software U and no other possible machine (such as trojan horse software
T)?
I's say "No" because there is no such finite string. There are many
other languages (sets of strings) to which any particular string
belongs. There is no finite string that belongs to just one language (or
one set of strings) out of the set of all possible sets of strings. So
just checking the string that came from the voter cannot rule out it
came from a language that is not the same as the language associated
with U.
A Turing machine M that took the user's actual input into the (unknown)
application, a description of U and the received string (choice) could
simulate U with the actual input, compute the expected selection and
compare it against the received selection and thus catch the fraud. BUT,
the vote collector never gets a copy of the actual input the voter made
into the application at voter's end of things.
In fact, the language (set of strings) of U is not the same as the
language (set of strings) from T. Suppose T only sends out the same
string (choice) no matter what the voter selects, for example.
So here's an interesting twist to this situation; try to detect the
differences in the languages of U and T:
Suppose the voter chooses each of n possible candidates in some known,
defined order and applies encryption and authenticati
Cryptography-Digest Digest #185
Cryptography-Digest Digest #185, Volume #12 Sun, 9 Jul 00 16:13:01 EDT
Contents:
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Q: Hadamard transform (Mok-Kong Shen)
Yet another uncommon number system (Mok-Kong Shen)
Re: Quantum Computing (Was: Newbie question about factoring) (Jerry Coffin)
Re: Using CRC's to pre-process keys (Jerry Coffin)
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
("tok")
Re: A thought on OTPs (Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical (Samuel Paik)
Advanced Cryptography FAQ ([EMAIL PROTECTED])
Re: Proposal of some processor instructions for cryptographical (Samuel Paik)
Re: computer program: extract consonants/vowels from input (JPeschel)
Re: Proposal of some processor instructions for cryptographical("Trevor L.
Jackson, III")
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 20:18:06 +0200
Kasper Pedersen wrote:
"Mok-Kong Shen" [EMAIL PROTECTED] wrote
I implicitly assume a common processor, e.g. what people normally
have access to, e.g. a PC.
Aren't we already talking specialty items? Maybe people _will have_, but
they certainly don't _have_
I mean crypto software that is to be used by common people, i.e.
without requiring them to purchase any special hardware.
The problem is with the size of the look-up table and quite probably
also the efficiency incurred thereby in case the permutation is
dynamically
determined so that one has to recompute the look-up table frequently.
Which is acceptable on fixed perms. A 32:32 mapping can be done in 4 clks on
a modern CPU, the 16 kbit memory for the table the limiting factor as we
assume 1 load per clock. But - that memory isn't much bigger than the 32:32
switch matrix on the silicon, and it's a lot more powerful.
Dynamically changing perms of this kind are fun - but you can probably find
something that's more cryptographic value for the cost.
Well, if I don't err, for a given particular permutation one has to
have a look-up table of 2^32 words as an array. Isn't that fairly huge?
And one has to compute the contents of these, even if done only once
in a key dependent way.
Perhaps I misunderstood you. But it is not a matter of formal formulation,
it is a matter of implementation (with processor instructions).
Which is why he's talking FIR filters. DSPs have special instructions for
those, optimized to such a degree that they sometimes take up most of the
silicon. Take the sample C code below
for (i=0; in; i++)
{
acc+=data[p1+base_p1]*data[p2+base_p2];
p1=(p1+1) mod size_p1;
p2=(p2+1) mod size_p2;
}
A typical low-cost DSP will do the above loop in 1+n clock cycles. The above
{...} is one instruction in the CPU, and the for(;;) is free (typically 1
clk setup).
And with a little headache, it can be implemented in 3DNow! at 1 clock/round
v. 32*32, for those running K6-x or K7's.
Notice how well it moves bits around?
The context in the above case was computing the parity. Does
Data[index] of your code refer to a single bit? Thanks.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 20:23:10 +0200
Thomas Womack wrote:
"Mok-Kong Shen" [EMAIL PROTECTED] wrote
Transposition is one of the basic operations in cryptography.
Is it, any more? Having a look at the AES candidates, most of them carefully
refrain from calling for bit transpositions simply because they're rather
hard to implement.
Given that, I think that one should get hardware support for transpositions.
If you want byte transpositions, Altivec has a vector-permute instruction
which considers one 128-bit register as a list of 16 bytes A[0..15],
considers the lower bit of each byte as an index into a second register B
(also considered as a set of 16 bytes B[0..15]), and sets C[i] = B[A[i]]. I
don't know how long this instruction *takes* on a current G4, but someone in
comp.arch surely does.
Anyway, byte transposition in memory is always supported, if I don't err.
The bit scatter/gather technique you suggest seems to go very against the
RISC philosophy by having a single instruction require hundreds of memory
operations; I think you have to stick with permutations that can fit in a
register, though there's nothing stopping you from suggesting a
super-Altivec using 256-bit vector registers.
Actually I don't think that a general bit permuation instruction is very
extravagant. There is, if I don
Cryptography-Digest Digest #185
Cryptography-Digest Digest #185, Volume #11 Wed, 23 Feb 00 07:13:01 EST
Contents:
I have added few images of my notebooks to alt.politics.org.cia ("Markku J.
Saarelainen")
need help! decryption (jamie)
Re: Passwords secure against dictionary attacks? (John Underwood)
Re: OAP-L3 Encryption Software - Complete Help Files at web site ("Douglas A. Gwyn")
Re: need help! decryption (Elgar)
Re: EOF in cipher??? (Mok-Kong Shen)
Re: Processor speeds. (Mok-Kong Shen)
Re: Passwords secure against dictionary attacks? ("Steve Coath")
cannot understand CFB mode code.. ([EMAIL PROTECTED])
Re: Passwords secure against dictionary attacks? ("Ken Hagan")
Transmitting ciphered data ("Markus Eiber")
First announcement for ECC 2000 (Alfred John Menezes)
Re: Passwords secure against dictionary attacks? ([EMAIL PROTECTED])
Re: Passwords secure against dictionary attacks? (Michel Dalle)
Re: need help! decryption (Runu Knips)
Re: I am really scared of my NT ([EMAIL PROTECTED])
Re: Stuck on code-breaking problem - help appreciated ("jdc")
Re: Does the NSA have ALL Possible PGP keys? ("csabine")
From: "Markku J. Saarelainen" [EMAIL PROTECTED]
Crossposted-To:
alt.2600,soc.culture.russian,soc.culture.soviet,soc.culture.nordic,soc.culture.europe,soc.culture.german,soc.culture.ukrainian,soc.culture.china
Subject: I have added few images of my notebooks to alt.politics.org.cia
Date: Wed, 23 Feb 2000 07:05:31 GMT
I have added few images of my notebooks to
alt.politics.org.cia
all these are intelligence related .. I still have hundreds of pages of
my notebooks that I have to review for you ..
other posted diary and notebook entries are at
http://homestead.virtualjerusalem.com/waeg/Diaries.html
Visit also the Game of General (M) (updated with the language - actually
I can teach the language to you more clearly - it is quite simple but
very effective) at
http://homestead.virtualjerusalem.com/waeg/gameofm.html
Best regards,
Markku
--
From: jamie [EMAIL PROTECTED]
Subject: need help! decryption
Date: Wed, 23 Feb 2000 07:48:36 GMT
This arrived in my email and I have no idea what it is, can someone tell
me how to decypher it?
Thanx in advance...
Subject:
¯u¹êªº¬G¨Æ¡A½Ð§A§Ú¤@»ô¨ÓÃö¤ß
From:
Nothing [EMAIL PROTECTED]
¡@¡@±z¦n¡A«Ü©êºp¡A¥´ÂZ±zÄ_¶Qªº¦¬«H®É¶¡¡A³o¨Ã¤£¬O¤@«Ê¼s§i«H¡A¦Ó¬Oµo¥Í¦b§ÚªB
¤Í¨¤Wªº¤@¥ó¯u¹êªº¬G¨Æ¡AÁöµM§Ú¨Ã¤£»{Ãѱz¡A±zªº¶l¥ó¦ì§}¤]¬O§Ú±qºô¸ô¤W©Ò¨ú±o
ªº¡A¦ýÁÙ¬On½Ð±zªáÂI®É¶¡±N³oÓ¬G¨Æ¬Ý§¹¡A¦pªG¥i¥Hªº¸Ü¡A½Ð±N³o«Ê«H¶Çµ¹±zªºªB
¤Í¡AÁöµM«H¤¤´d¼@ªº¥D¨¤»P±zµLÃö¡A¦ý¦pªG¥xÆW¥æ³q°ÝÃDÄ~Äò¦p¦¹¡A½Ö¤]¤£´±«OÃÒ¤U
¤@¬í´d¼@·|¤£·|´Nµo¥Í¦b§Ú̪ºªB¤Í¡Ð¡Ð¬Æ¦Ü¬O§Ú̦ۤv¨¤W¡A½Ð¦@¦Pn¨D§Ú̪º¬F
©²¤Î¨ä©xû¡A»P¨ä¥u·|¦b¿ïÁ|®É¥´°ªªÅ¡A»¡¨Ç¨¥¤£¤Î¸qªº¨¥½×¡Aˤ£¦p¯uªº©ñ¤@ÂI¤ß
«ä¦b§Ú̳o¨Ç¤p¦Ñ¦Ê©m¨¤W¡AÅý§ÚÌ¥i¥H¦³¤@Ó§K©ó®£ÄߪºÀô¹Ò¡C
¡@¡@¥H¤U¬O¥ØÀ»ªÌ©Ò¼gªºì¤å¡A«H¤¤©Î³\¦³¨Ç¿ù¦r¡A¦ý¬°´L«·í¨Æ¤H¡A§Ú¨Ã¤£¥[¥ô¦ó
ªº×§ï¡A«H¦³ÂIªø¡A½Ð±z@¤ß§â¥¦¬Ý§¹¡C
©M¦o»{ÃѬO¦b©_¼¯ªººô¸ô¤W,¨º¤@¤Ñ§Ú̲᪺«Ü¶}¤ß,¶¢½Í¤§¤¤§Ṳ́~ª¾¹D§ÚÌ¦íªº¬O
¦p¦¹£xªñ¦]¦¹§Ṳ́¬¬Û¯d¤U³q°T¤è¦¡,«á¨Ó§Ṳ́§¶¡³q¹L¤F´X¦¸¹q¸Ü,¨º¤@¤Ñ±ß¤W§Ú¨{
¤l¾j¤F,©p»¡n±a§Ú¥h¦YªF¦è,¦]¦¹§ÚÌ´N¬ù¥X¨Ó¦Y®d©],¨£¨ì©p,©p¤ñ§Ú·Q¹³¤¤£x©pÁÙ¥i
·R,¦b¦Y¶º¤§¤¤ª¾¹D©p£x®a®x,©p£x¤@¤Á,ì¨Ó©p¬O¤@Ó¨º»ò°í±j£x¤k¥Í,¤@Ó¤H¯²«Î¦b¥~
±ÁÈ¿ú¾i¬¡¦Û¤v,¨º®ÉÔ£x§Úı£x¦Û¤v©M©p¤ñ°_¨Ó©¯ºÖ¤Ó¦h¤F,¦^¥h¤§«á§Ṳ́S¶¢²á¤F
¤@¨Ç,©p§i¶D§Ú©p·Q¾Ç^¤ån§Ú±Ð©p,§ÚµªÀ³¤F©p§i¶D©p§Ú£x½Ķ¾÷¨S¦³¥Î¥i¥HÉ©p,©p
Å¥¤F«Ü°ª¿³,«á¨Ó©p§i¶D§Ú©ú¤Ñn¦^ªO¾ô£x°®¶ý®a,¥i¯à·|¥h´X¤Ñ,¦^¨Ó«á·|¥´¹q¸Üµ¹§Ú,
§Ú§i¶D©p¦^¨Ó«á¤@°_¥h°Ûºq,©pµªÀ³¤F§Ú.
¬P´Á¤@£x¤U¤È¥x¥_¤U°_¤F«B,¤Ñ®ð¦³ÂIÀã§N,¥´¹q¸Üµ¹©pª¾¨ì©p¤H¦b¥x¥_,è¦^¨Ó,§Ú°Ý
©pn¥h°Ûºq¶Ü?©pµªÀ³¤F§Ú,«á¨Ó§Ú¬ù¤F¥t¥~¤TÓºô¤Í¥h°Ûºq,§Ų́º¤@¤Ñ°Ûºq°Û£x«Ü¶}
¤ß,¬P´Á¤T£xâ±á§Ú̦b½u¤W¸I¤F±,¨º¤Ñ¤Ñ®ð¤]¬O¯S§O£x§N,¥~±ÁÙ¤U°_¤F«B,©p§i¶D§Ú
·Q¸ò¥t¤@Óºô¤Í¥h¸õ»R,n§Ú¸ò©p¤@°_¥h,§Ú°Ý©p¬°¤°»ò?©p¦^µª§Ú¦]¬°§Ú¤H¦n,¦Ó¥B¥h£x
¸Ü¥i¥H«OÅ@©p,¦Ó¥B©p¤]¤£·|µL²á,¥i¬O§ÚÁÙ¬O¶û¥~±¤Ó§N¤F,§Ú¥u·Q¥h¦Y®d©]¤£·Q¥h¸õ
»R,«á¨Ó©p¦³ÂI¤£°ª¿³¥i¬OÁÙ¬O§i¶D§Ú¨º¤£µM¤j®a¬ù¥X¥h¦Y®d©]¦n¤F,©pª¾¹D§Ú·Q¦Y¨¡
¶ê,»¡n±a§Ú¥h¦Y¤@®a¦n¦Y£x©±,¨º¤@¤Ñ§Ú¬ï¤F²D¾c¬ï£x«Ü¥ð¶¢,¨£±«á©p¥´¶q¤F§Ú¤@¤U,
¯ºµÛ¹ï§Ú»¡,¨þ¨þ~~~§A¦nµl¤l³á!!§Ú¤]¯º¤F¯º!¦^µª©p§Ú¥»¨Ó´N¬Oµl¤l¹À!!¤£µM«ç»ò·|¤j
®a³£·R©O?©p¯ºµÛ¹ï§Ú»¡¹ï§r!¹ï§r!¦]¬°©pÁy¥Ö«p¹À!«á¨Ó§ÚÌ´N¸ò¥t¥~¨âÓºô¤Í¥h¦Y®d
©],°e©p¦^®a£x¸ô¤W,§Ú̦bÃM¼Ó¤U²á¤F¤@·|,©p§i¶D§Ú·Q¦^³Ìªñ¥i¯à·|¦^ªO¾ô£x°®¶ý®a,
§Ú»¡¨SÃö«Y§ÚÌÁÙ¬O¥i¥H«Ü±`¨£±£x,¦^®a«á¨ì¦¤W§Ú¤~ºÎµÛ!!
³Ä±ß¤»ÂI¦h°_§ÉÅ¥¨ì¤â¾÷©p£x¯d¨¥,©p»¡§Ú¦n½Þ³á!!ºÎ¨ì²{¦bÁÙ¨S¿ôn§Ú»°§Ö°_§É,¦³
¦n±d£xn¤¶²Ðµ¹§Ú!!Å¥§¹¯d¨¥«á§Ú°¨¤W¦^¤F©p¹q¸Ü,©p½|§Ú¯u·|ºÎ,§Ú¯º¤F¯º°Ý©p¤°»ò¦n
±d£x§r?©p§i¶D§Ú¦³Óºô¤Ín½Ð¦Y¤õÁçn±a©p¸ò§Ú¥h,§Ú»¡¥L¤S¤£»{ÃѧÚ,©p»¡©p¦³§i¶D
¹L¥L¤F§r?§Ú¯ºµÛ°Ý©p¬°¦ó¨C¦¸¸òºô¤Í¥X¥h³£n§Ú³§r!©p¯º¯º£x»¡¦]¬°§Ún«OÅ@©p§r!!
¨þ¨þ...§Ú¬ðµMÅܦ¨©p£x¤p¸ò¯Z¤F§Ú§i¶D©p!!²á¤F¤@¤U,©p§i¶D§Ú¦³Óºô¤Í±H·Ó¤ùµ¹©p,§Ú
»¡§Ú¤]n¬Ý,©p¥s§Ú§Ö¤Wºô,§ÚÌ´N¦bºô¸ô¤W²á¤F°_¨Ó,©p§â·Ó¤ù¶Ç¤F¹L¨Ó,¦b²á¤Ñ«Ç¤¤,§Ú
§i¶D©p§Ú©ú¤Ñn¦^]®
