Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #14 Fri, 8 Jun 01 05:13:00 EDT Contents: Re: DES not a group proof (David A Molnar) Algorithms (abhijeet) Re: Brute-forcing RC4 (S Degen) Re: Simple C crypto (Nicol So) Re: Def'n of bijection (Tim Tyler) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and (Mok-Kong Shen) Re: Some questions on GSM and 3G (Mok-Kong Shen) Re: DES not a group proof (Pascal Junod) Re: Best, Strongest Algorithm (gone from any reasonable topic) ([EMAIL PROTECTED]) Re: Def'n of bijection ([EMAIL PROTECTED]) Re: Def'n of bijection (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: Def'n of bijection ([EMAIL PROTECTED]) Re: Def'n of bijection (Tim Tyler) From: David A Molnar [EMAIL PROTECTED] Subject: Re: DES not a group proof Date: 8 Jun 2001 07:13:37 GMT JPeschel [EMAIL PROTECTED] wrote: bucks and it appears to be a book and a CD. The on-line review, however, says the CD isn't easily readable. Has anyone here actually seen the product? I picked up what must have been one of the first copies. It's a godsend when trying to find papers like this. Every paper available in PDF format, most of them from scans of the original. Some of the earlier volumes are difficult to read onscreen, but I've never had any problem reading the printed versions. (I always print everything out anyway; better to mark the margins). It's a bargain at the price. Especially if you don't have a well-equipped library nearby. -David -- From: [EMAIL PROTECTED] (abhijeet) Subject: Algorithms Date: 8 Jun 2001 00:33:01 -0700 Hi, I am writing my thesis on cryptography in Digital signature. Can anyone suggest me of any book or paper where I can get the full C or C++ code for the algorithms. thanking you regards -- From: S Degen [EMAIL PROTECTED] Subject: Re: Brute-forcing RC4 Date: Fri, 08 Jun 2001 09:36:53 +0200 Scott Fluhrer wrote: S Degen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse depending on the processor-speed, but lets say a PIII 500) This is the case: You have a 128 bit (ASCII) text, and the encyphered version of it. This version is encyphered with a 64 bit secret key, but of those 64 bits, 24 bits are known. (Leaving 40 unkown bits) I would like to know how long it would approximately take to calculate the 40 bit secret key. Would you mind very much if I asked what system you were attacking? Ofcourse not, dear sir. I am relating to the encryption of data in a Wireless LAN. The 802.11 protocol has a 'mode' where the server uses an encryption challenge to authorize a client. Both the server and the client have the same secret key. The server sends the client a plaintext challenge (unencrypted) and the client sends the encrypted challenge back, including the Initialisation Vector used. The server checks if the key that the client used is the correct key. The key used for encryption is 64 bits, but the (known) IV is 24 bits. This leaves 40 bits of the key unknown, but with the plaintext and encrypted challenge available, it should be possible to figure out the key. -- poncho -- From: Nicol So [EMAIL PROTECTED] Subject: Re: Simple C crypto Date: Fri, 08 Jun 2001 03:41:17 -0400 Reply-To: see.signature Dirk Bruere wrote: Why even bother with crypto? Just xor the file with 0xAA. Quite likely a variant of that will be used, unless there is some almost-as-simple and stronger alternative. Hence my inquiry. If you're willing to even consider simple obfuscation scheme like XOR'ing with 0xAA, you can do better by XOR'ing the text to be obfuscated with a pseudorandom sequence generated by the random() library function of your development tool. Typically you can control the pseudorandom sequence by specifying the seed. This is very simple to explain to a programmer/coder, although it provides little security in a real sense. However, that seems to be what you're looking for. -- Nicol So, CISSP // paranoid 'at' engineer 'dot' com Disclaimer: Views expressed here are casual comments and should not be relied upon as the basis for decisions of consequence. -- From: Tim Tyler [EMAIL PROTECTED] Subject: Re: Def'n of bijection Reply-To: [EMAIL PROTECTED] Date: Fri, 8 Jun 2001 07:39:23 GMT [EMAIL PROTECTED] wrote: : Tim Tyler [EMAIL PROTECTED] writes: : [EMAIL PROTECTED] wrote: :: Um, it's a mathematical term, Tim. A statement is vacuously true when :: it cannot possibly be false. In other words, the statement contains :: no information. : : I guess you think Fermat's Last Theorem is vacuous, then. It's negation : is known to be an impossiblity, after all. : No. Read it again
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #13 Fri, 26 Jan 01 19:13:01 EST
Contents:
Re: Producing "bit-balanced" strings efficiently for Dynamic ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Encoded serial number:Help! (Giannikol)
Q: solving simultaneous equations in modulo arithmetic (G. Ralph Kuntz, MD)
Re: Some Enigma Questions (Neil Sluman)
Re: Random stream testing. (long) ("Joseph Ashwood")
Re: Some Enigma Questions (John Savard)
Re: Some Enigma Questions (John Savard)
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Terry
Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Tony T. Warnock" [EMAIL PROTECTED]
Subject: Re: Producing "bit-balanced" strings efficiently for Dynamic
Date: Fri, 26 Jan 2001 15:19:06 -0700
Reply-To: [EMAIL PROTECTED]
Arbitrary 37 bit strings will fit into 40 bits. 2**37 is just larger
than 40!/20!**2. I didn't check to see if the suggested algorithm would
actually work.
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:21:52 GMT
On Fri, 26 Jan 2001 09:07:03 -0800, in
[EMAIL PROTECTED], in sci.crypt "Paul Pires"
[EMAIL PROTECTED] wrote:
[...]
I also am not clear on the goal. Yes there needs to be bit balancing so that
a bias in the input is not recognizable in the output but by doing this
hiding,
don't you sacrafice another valuable property? Seems like the output would
fail a taylored randomness test. You are going to get data that has a
prefect
distribution of zero's and ones within a block and something else if the
block
reference is displaced. Right?
It is not necessary for strength or security that a cipher to produce
random-like output. Most ciphers do so, but such is not necessary.
Here I think the possible output codes do appear with equal
probability.
This is a characteristic which represents the inefficiency of balanced
coding. But since that is a plaintext coding, and is known by both
designer and opponent, it does not seem particularly worrisome.
Seems like what you'd want would be a method where the transposition
works on a pile that is "Probably" balanced but where the deviation from
perfect is not correlated to the input or output. I could be screwy here.
I have mentioned the possibility of a statistical or "almost" balance,
which could be very effective. But it seems like that analysis would
be much more complicated. We would have to talk about the
distribution of balance, and how strength changes accordingly, which
seems beyond what can now be done.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:25:04 GMT
On Fri, 26 Jan 2001 12:07:40 -0700, in
[EMAIL PROTECTED], in sci.crypt "Tony T. Warnock"
[EMAIL PROTECTED] wrote:
I have a suggestion for the initial statistical-balance step (to reduce
the later balance extensions.) XOR the input with a DeBruijn sequence.
For example a simple method would be to XOR the sequence 0101010101
Better would be 001100110011 and even better 0001011100010111 In
the latter case, the XORing sequence is one byte long so one might
improve things by rotating this sequence between bytes. Longer
sequences are possible 10011010 could be used on pairs of
bytes--with rotation.
If we are going to process plaintext with a known sequence, why should
any particular balanced sequence be better than any other? It seems
like there will always be some plaintext that will not be helped, or
would in fact be made worse.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:26:55 +0100
Terry Ritter wrote:
Mok-Kong Shen[EMAIL PROTECTED] wrote:
After some re-thinking, I do like to elaborate a little
a previous point of mine concerning the question of
perfectness of DT.
Suppose we have block size of n and we agree not to use
the non-balanced groups of bits but only the balanced
ones to transmit informations (in other words, we have
an 'alphabet' of a cer
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #12 Tue, 29 Aug 00 04:13:01 EDT Contents: Re: secrets and lies in stores (S. T. L.) Re: New algorithm for the cipher contest (David Hopwood) Re: encryption scheme output - samples table? (David Hopwood) Re: Asymmetric Encryption Algorithms (David Hopwood) Re: "Warn when encrypting to keys with an ADK" (David Hopwood) Re: UNIX Passwords (David Hopwood) Re: Future computing power (Anders Thulin) Re: could someone post public key that is tempered ? (jungle) Re: Steganography vs. Security through Obscurity (Benjamin Goldberg) Re: On pseudo-random permutation (Bryan Olson) Re: On pseudo-random permutation (Markku-Juhani Saarinen) Re: Looking for Book Recommendations ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] (S. T. L.) Date: 29 Aug 2000 05:15:15 GMT Subject: Re: secrets and lies in stores Because it doesn't deny the above. It points this out. Then notes that having a perfect lock is not enough. There is a lot more to security, and the way people think about it, and act in a society which has certain kinds of locks, than the lock itself. So much else that often focusing on the lock alone leads us to miss much larger points. That's what I meant by "hardly relevant. Hmmm. I still don't like the idea of calling any field of mathematics or science hardly relevant, no matter how it fits into society. You could call supersymmetry in particle physics completely irrelevant because it'll never affect society. But that doesn't say anything about how important it is to investigate this area. Same with cryptography. Of course, now I'll have to read this danged book to see what it's all about. Heh. Too little time, too many books. If there's such a thing as too many books, that is. :-P -*---*--- S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site. My upgraded Book Reviews Page: * http://sciencebook.cjb.net * Optimized pngcrush executable now on my Download page! Long live pngcrush! :- -- Date: Tue, 29 Aug 2000 06:38:48 +0100 From: David Hopwood [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: New algorithm for the cipher contest =BEGIN PGP SIGNED MESSAGE= Scott Fluhrer wrote: I believe I have a way that, given K[3] (which is the fourth multiplicative key), distinguishes it from randomness with a relatively few amount of chosen plaintexts and effort, and the actual chosen plaintexts do not depend on K[3]. This immediately leads to a method of rederiving K[3] with about O(2**64) effort and circa 100-1000 chosen plaintexts. Drat, beat me to it :-) I was working on exactly the same attack; I'd done the second case for the distinguisher, and was close to working out the first one. - -- David Hopwood [EMAIL PROTECTED] Home page PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip =BEGIN PGP SIGNATURE= Version: 2.6.3i Charset: noconv iQEVAwUBOasmtTkCAxeYt5gVAQG4Mgf9Hgnap4TeE8+IhK4yTGYnENF5sRbp52ox Ynrod5UkcDm/3YDcflsFnwo92uHtNrYumCTqUpuPwx9R5Igr4ZcB5of2aoLHcBRB vtA8iNz2mXMdsFo7PkBdZDQLd/1RYk+Su3NdIZBm19g60OUvhThPGJf1ASoXpCy/ MxL/ggwaG2oRpFEqwa4mEfEihQmMAHWUsu7MGXX21+kwHADHfjVJ4gOijYTMUDI8 dqXzpdbMamIFmHM0cD0zZALukn9Zx+96B5U54iRflzQzeKiPc5xNSSQMr+xa570O Qd/uuhloDCLdgD9ZXtE9Jw4/PV5oioWl6LrknzrAJYye1rz99fRBXw== =Y3LY =END PGP SIGNATURE= -- Date: Tue, 29 Aug 2000 06:38:55 +0100 From: David Hopwood [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: encryption scheme output - samples table? =BEGIN PGP SIGNED MESSAGE= kihdip wrote: Most encryption schemes result in a bitstream. To be more precise, most modern encryption schemes treat plaintext and ciphertext as streams of octets (8-bit bytes), or occasionally as streams of larger words (e.g. 32 bits). The order of bits within an octet or word is usually not defined. - -- David Hopwood [EMAIL PROTECTED] Home page PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip =BEGIN PGP SIGNATURE= Version: 2.6.3i Charset: noconv iQEVAwUBOasxBjkCAxeYt5gVAQGRQwgAk0DXNEeFse75HCp5GyVRCXhmAlCMi57p Qw75mKHyP2LeK0FccuN+okTRyn0JzKSFVYY63wKK7UUHhySdzdjqkjo6WjCwn6XQ lGlBap2WB4TXVB7Pwm9XDWPC2UVOtqmO+1n90vNSEiBqIeRClf1Ovq7x58cQ0Rb1 cTQ0U8AdId1QeTvZrSzw0TgJEdGsTSeym1
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #11 Mon, 17 Apr 00 08:13:01 EDT
Contents:
Re: Q: source code for recognizing English (Guy Macon)
Re: Paper on easy entropy (Steve Roberts)
Re: Non-standard shift register sequences ("Al Grant")
Re: GOST idea (Tom St Denis)
Re: GOST idea (Tom St Denis)
Re: Is AES necessary? (Tom St Denis)
Re: Paper on easy entropy (Tom St Denis)
Re: Paper on easy entropy (Tom St Denis)
Re: My STRONG data encryption algorithm (Pred.)
Re: Paper on easy entropy (Guy Macon)
Re: ? Backdoor in Microsoft web server ? [correction] (Francois Grieu)
Re: Paper on easy entropy (Tom St Denis)
Re: Regulation of Investigatory Powers Bill (Tom St Denis)
Re: Key exchange using Secret Key Encryption (Jaime Cardoso)
For Mike Rosing (by JOKER) (=?iso-8859-1?Q?Jos=E9?= Antonio Fuentes
=?iso-8859-1?Q?Fern=E1ndez?=)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Q: source code for recognizing English
Date: 17 Apr 2000 06:27:21 EDT
In article 8deanh$ohd$[EMAIL PROTECTED], [EMAIL PROTECTED]
([EMAIL PROTECTED]) wrote:
I am working on a simple program to decipher simple substitution
ciphers. The most important part of the program is to try
various substitutions using AI techniques (forward-chaining and
backward-chaining) using certain assumptions, i.e. English language
frequencies of letters, double-letters (ll,ss,ee,oo), triple letters,
list of most frequent two- and three- letter words. I have some
difficulties though. So if anyone has a source code for a similar
program, I would be IMMENSELY thankful. Please, write to
[EMAIL PROTECTED]! Thanks a lot in advance,
Just out of curiosity, do you parse the entire message or stop
when you notice that part of it is clearly not any language?
The first defeats the random garbage before and after the plaintext
trick, but the latter seems like it would let you make more tries
per second.
--
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: Paper on easy entropy
Date: Mon, 17 Apr 2000 10:21:49 GMT
"Joseph Ashwood" [EMAIL PROTECTED] wrote:
Does anyone have a suggestion as to what
software to use?
I've had no problems with gsview. It's available at
http://www.cs.wisc.edu/~ghost/
Joe
I have had problems with installing GSVIEW and it crashed when looking
at certain pages. Itr may have been the way my PC was set up though.
Instead I now convert PS to PDF using Acrobat Distiller and can then
use the whole power of Acrobat to look at it, print it etc.
Steve Roberts
--
From: "Al Grant" [EMAIL PROTECTED]
Subject: Re: Non-standard shift register sequences
Date: Mon, 17 Apr 2000 11:50:02 +0100
"Peter L. Montgomery" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
In article 8d1eg8$dns$[EMAIL PROTECTED]
1. use of a value computed from previous outputs, e.g.
A_i = A_{i-n} + sum(A_0 to A_{i-1})
where the sum is computed by updating an accumulator
with each new output
This is easily converted to a standard shift-register
recurrence, with appropriate initial conditions. Note
A_i - A_{i-n} = sum(A_0 to A_{i-1})
= A_{i-1} + sum(A_0 to A_{i-2})
= A_{i-1} + (A_{i-1} - A_{i-n-1})
Yes, that particular example can be converted but in the general
case it can't be. Do you know of examples of use of this kind
of "accumlator" to strengthen a shift register?
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: GOST idea
Date: Mon, 17 Apr 2000 10:52:42 GMT
Mok-Kong Shen wrote:
Tom St Denis wrote:
That's too vague, sorry. It can't hinder it in this case since the S
function is simply a permutation itself. And since the quadratic
used is a permutation it has no bias towards any particular value. It's
like doing
F(x) = S(x + c), For any constant 'c'. You are just changing the order
of the outputs, not the properties of S() itself.
Maybe I misunderstood. My point is the following: If v is the
input and w the output and one knows that between v and w there
is a certain avalanche property, i.e. the effect of flipping
one bit of v. Now suppose I have a mapping of u to v that is a
permutation. Two values u1 and u2 differing only in one bit
may have the corresponding values v1 and v2 differing in many
bits and their resulting effect on a comparison between w1 and
w2 may not be simple to tell.
With the original F function flipping one bit of the input changes only
two bits on avg of the output. In the next round there are hopefully
two active sboxes now... etc..
With the quadratic changing a lsb can change several sboxes. It's not
guranteed to increase the active sbox count but it does help. For
example if you change any of the top four bits, then there is still only
one active sbox. But in the next F func
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #9 Wed, 19 May 99 02:13:02 EDT
Contents:
Hash Program (Jim Dunnett)
Re: How to understand/program more advanced crypt. ("Matthew Bennett")
Re: Can Somebody Verify My DES execution? (Richard Outerbridge)
Re: Hello I am paper, please read me. ([EMAIL PROTECTED])
remailers ([EMAIL PROTECTED])
Re: remailers (Paul Rubin)
Re: Computer-generated random numbers (was Re: Magic) ([EMAIL PROTECTED])
Re: symmetric boolean functions ("Russell Easterly")
Re: prime numbers and the multplicative inverse (Boris Kazak)
Re: Hash Program (Boris Kazak)
Need to design basic authentication system ("Tim Mavers")
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Hash Program
Date: Tue, 18 May 1999 20:40:09 GMT
Reply-To: Jim Dunnett
Anyone know from where (or if) I can obtain an
MSDOS/Windows executable to 'distill' hardware
produced bits by 'hashing'?
--
Regards, Jim.| Gouverner, c'est choisir.
olympus%jimdee.prestel.co.uk |
dynastic%cwcom.net | - Duc de Lévis 1764-1830
nordland%lineone.net |
marula%zdnetmail.com |
Pgp key: pgpkeys.mit.edu:11371
--
From: "Matthew Bennett" [EMAIL PROTECTED]
Subject: Re: How to understand/program more advanced crypt.
Date: Tue, 18 May 1999 23:16:39 +0100
This might be an interesting, and simple, one to try out (I've yet to code
it myself though..)
TEA (Tiny Encryption Algorithm)
http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
It includes source code and some strength analysis.
/\/\/\//
Mika Stenberg wrote in message [EMAIL PROTECTED]...
Hi,
Im really new into Cryptography, and I was wondering if someone could
explain (Maybe with an example program of C / Java / Pascal) how to
code a little more advanced crypt. program. Advanced would mean
something else than just replacing chars with another ones.
Mika
--
From: [EMAIL PROTECTED] (Richard Outerbridge)
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 18:39:32 -0400
1999-05-18 18:20:01 EDT
In article 7hrk7q$8do$[EMAIL PROTECTED], [EMAIL PROTECTED] (Thomas Pornin) wrote:
The DES standardization paper should include some test vector. There is
also an implementation in Bruce Schneier's "Applied Cryptography" ; be
sure however that you use the second edition, since the first is a bit
buggy (the P permutation is reversed, for instance). It contains the
following test vector : [snip]
Yeah, that's mine. As has been mentioned in this thread a single test
vector only gives a first-order assurance of correctness, but I'm pretty
sure that the AC2 code is correct. Other first-order tests, remarkably
useful in tracking down bugs, are:
a) verify that the weak-key property holds (encrypt twice using the same
weak key equals pt for all four weak-keys);
b) verify that the semi-weak-key property holds (encrypt under key 1,
decrypt under key 2, equals pt, for all six pairs of semi-weak-keys).
NIST has also published a test suite which can identify bitwise flaws
in various parts of an implementation, and Ron Rivest came up with an
abbreviated test which (if passed) verifies correctness for almost all
single-bit errors.
If anyone would like arbitrary test-vector triples from an implementation
I'm pretty sure of, feel free to ask.
outer
--
"Just an eccentric soul with a curiosity for the bizarre."
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED]
Subject: Re: Hello I am paper, please read me.
Date: Tue, 18 May 1999 23:34:36 GMT
In article 7hovbq$9dp$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I thought the shuffling was supposed to produce a pseudo random
permutation. Did you actually look at the decks after 8 or 16
shuffles? You certainly don't need any shuffling bisectors to
notice the patterns.
The problem is that trying to shuffle the deck with only one value
will
always leave patterns. RC4 over comes this by using the deck as
paramters and the key (over and over).
I can't tell what you're talking about. What does shuffling with
only one value mean, and what does it have to do with your keying
procedure? It looks like your initial key set-up shuffles once
for each byte of key. Try it with 8 or 16 bytes.
Why do you think RC4 ever had any such problem to overcome?
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
Subject: remailers
From: [EMAIL PROTECTED]
Date: 18 May 1999 21:40:55 -0400
I just sent a series of tests through several anonymous remailers;
most of them had a latency of several days. Is this a built-in latency
to frustrate traffic analysis, or are they just slow? Are there any
fast remailers? Is there a more appropriate venue for askin
