List Info

Thread: How to match recursive blocks when begin goes over two lines




How to match recursive blocks when begin goes over two lines
user name
2006-09-15 13:26:50
Hi,

I am slowly adapting to the language defs. Great.

Now, I am having difficulties to specify recursive blocks
for a  
language.
So far, I got it working pretty good for things like

-----------------
%function foo() {
   %{
   %}
%}
-----------------

as I created a matcher for {%..%} that calls itself and thus
the matcher
for the function which for simplicity I state here as

begin = '%function .*\(\) \{'
end   = '%}'

will match the last %} and not the previous one. Cool.

Now, how do I allow for this case:

---------------
%function foo()
{
   %{
   %}
%}
---------------

I can't get it to work even though I know that the matcher
only  
matches whole
lines. The language I try to define is an obsolete old IBM
mainframe  
macro
language called Net.DATA (please, don't ask why).

So a block starts either as '%keyword_and_more {' or as
'% 
keyword_and_more\n{'
and always ends in '%}'.

Is it possible to define this? I assume that I need to
define two  
rule sets to
simulate the two states and then either start in state A or
B and do the
recursion within each set. Right?

Andreas Pardeike


PS: If you like, you can see my current definition:

{	scopeName = 'source.netdata';
	fileTypes = ( '' );
	foldingStartMarker = '%.*\{|%(?i:if)';
	foldingStopMarker = '%\}|%(?i:endif)';
	patterns = (
		{	include = '#embeddedstuff'; },
		{	name = 'source.netdata.comment';
			match = '^%\{.*?%\}';
		},
	);
	repository =
	{	embeddedstuff = { patterns = (
				{	include = '#shtml'; },
				{	include = '#netdata'; },
			);
		};
		netdata = { patterns = (
				{	name = 'keyword.control.netdata.conditional';
					match = '%(?i:if|else|endif)';
				},
				{	name = 'keyword.control.netdata.include';
					match = '%(?i:include).*';
				},
				{	name = 'keyword.control.shtml.include';
					match = '<!--#%(?i:include).*-->';
				},
				{	name = 'source.netdata.block';
					begin = '(%\{(?i:macro)?)';
					end = '(%\})';
					captures = { 1 = { name = 'keyword.control.netdata';
}; };
					patterns = ( { include = '#embeddedstuff'; } );
				},
				{	name = 'source.netdata.function';
					begin =
'(%function\s*\(([^)]*)\))\s+(\w+\(.*\))\s*(\{)';
					end = '(%\})';
					captures =
					{	1 = { name = 'keyword.control.netdata'; };
						2 = { name = 'source.netdata.function.type'; };
						3 = { name = 'source.netdata.function.name'; };
					};
					patterns = ( { include = '#embeddedstuff'; } );
				},
				{	name = 'source.netdata.block';
					begin = '(%.*?)\s*\(.*\)\s*(\{)';
					end = '(%\})';
					captures =
					{	1 = { name = 'keyword.control.netdata'; };
						2 = { name = 'keyword.control.netdata'; };
					};
					patterns = ( { include = '#embeddedstuff'; } );
				},
				{	name = 'source.netdata.block';
					begin = '(%.*)\s?(\{)';
					end = '(%\})';
					captures =
					{	1 = { name = 'keyword.control.netdata'; };
						2 = { name = 'keyword.control.netdata'; };
					};
					patterns = ( { include = '#embeddedstuff'; } );
				},
			);
		};
		shtml =
		{	name = 'source.netdata.embedded.shtml';
			begin = '(?=<!--#)';
			end = '-->';
			patterns = (
				{	name = 'keyword.control.shtml.include';
					match = '(?i:include.*?=".*?")';
				}
			);
		};
	};
}

____________________________________________________________
__________
For new threads USE THIS: textmatelists.macromates.com
(threading gets destroyed and the universe will collapse if
you don't)
http://lists.macromates.com/mailman/listinfo/textmate
Real World Exploit for Bleichenbachers Attack on SSL from Crypto'06 working
user name
2006-09-15 07:52:43
Erik Tews writes:
> At least 3 major webbrowsers on the marked are shipped
by default with
> CA certificates, which have signed other intermediate
CAs which use
> rsa1024 with exponent 3, in their current version. With
this exploit,
> you can now sign arbitary server certificates for any
website of your
> choice, which are accepted by all 3 webbrowsers without
any kind of
> ssl-warning-message.

Is that true, did you try all 3 web browsers to see that
they don't give
a warning message?  It's not enough that they accept a CA
with exponent
3, they also have to have the flaw in verification that lets
the bogus
signature through.

If it is true, if three different widely used webbrowsers
are all
vulnerable to this attack, it suggests a possible problem
due to the
establishment of a cryptographic monoculture.  If it turns
out that
the same cryptographic library is used in all three of these
browsers,
and that library has the flaw, then this reliance on a
single source
for cryptographic technology could be a mistake.

Now in practice I don't think that Internet Explorer and
Mozilla/Firefox
use the same crypto libraries, so either these are not two
of the three,
or else they have independently made the same error.  It
would be nice
to know which it is.

Hal Finney

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com
Array
user name
1969-12-31 18:00:00

On 14 Sep 2006, at 22:01, Steve Foerster wrote:

Charles wrote:

Professor Gives Students the Option of purchasing His Lectures Online

This is the nice thing about taking courses online -- if things like
this are needed, they're also included in the tuition fee.

If I were providing videos of lecture online, I would find a sponsor, whose advertisements I would prefix and suffix onto the video.  If my target audience were American, I might even include a few bloopers at the end.

By charging a price, this professor a) reduces the quantity demanded for his videos, and b) creates yet another incentive for students to bootleg.  By distributing the videos for free, sponsored by advertising, the professor and the advertisers would have an incentive to promote the videos beyond this professor's immediate students.  The advertiser would very happy to learn that the videos were being accessed worldwide and should be willing to continue to pay promotional and placement fees for subsequent videos.

I am looking for a sponsor now, as I am developing a Finance class for a major university.  Although it is not part of my assignment, I want to develop ancillary videos and other materials through FCC that my class can use.

I will keep this list posted on my progress.

Charles Evans
Executive Director, Free Curricula Center



Exponent 3 damage spreads...
user name
2006-09-16 02:03:01
     --
James A. Donald:
 > > Obviously we do need a standard for describing
 > > structured data, and we need a standard that
leads
 > > to that structured data being expressed concisely
 > > and compactly, but seems to me that ASN.1 is
causing
 > > a lot of grief.
 > >
 > > What is wrong with it, what alternatives are
there
 > > to it, or how can it be fixed?

Bill Frantz wrote:
 > In SPKI we used S-Expressions.  They have the
 > advantage of being simple, perhaps even too simple.
 >
 > In describing interfaces in the KeyKOS design document
 > <http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosi
 > s/keywelcome.html> we used a notation similar to
 > S-Expressions which was:
 >
 > (length, data)

The trouble with S-expressions is that as with
ASN.1-DER, all data structure is specified at run time,
in the sense that the run time data can have any
structure whatsoever. Thus the program parsing the data
has to be able to handle all possible data structures
whatsoever - including unexpected data structures
ingeniously concocted by an adversary to exploit flaws
in the program.  Run time description of data structure
should be a special case, an exception.

If the data can parsed at run time, without advance
knowledge of how the data is supposed to be structured,
without knowing what the header signifies, then it is
possible for an adversary to create complications by
structuring the data differently from the way it is
expected to be structured.

We need a system where the structure of the data is
largely determined by the header, and usually entirely
determined by the header, which is an arbitrary
identifier, not a description of one of an infinite
variety of possible data structures.  The recipient sees
the header, knows therefore what the structure of the
data must be, and proceeds to parse it as having that
structure, and in fact there is should be no run time
internal structure. If you do not know what the header
means, you should not be able to parse the data.  If you
could, then the adversary could create unexpected
structure.

Alternatively, we could have a system that allows
arbitrary run time structure, but with a general purpose
filter that absolutely guarantees expected structure,
rather than the programmers checking structure ad hoc in
each particular program.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      10vNqS4ChWmjQinDgd1a61m4GCk0hxC9KXi2Hy+N
      4jgO2FPYh3FS3oJk07kNEMuYXdYZlJNtCqort+Lwh

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com
A note on vendor reaction speed to the e=3 problem
user name
2006-09-28 20:47:32
| > VMS has for years had a simple CHECKSUM command,
which had a
| > variant, CHECKSUM/IMAGE, applicable only to
executable image files.
| > It knew enough about the syntax of executables to
skip over
| > irrelevant metadata like link date and time.  (The
checksums
| > computed weren't cryptographic - at least the last
time I used it,
| > many years ago.  The command was created to use in
patches to
| > provide a quick verification that the file being
patched was "the
| > right one".)  I've always found it surprising
that no one seems to
| > have developed similar tools for Unix - with the Gnu
libraries for
| > portable access to object/ executable files, it could
be done
| > relatively easily.
| 
| The "sum" command has existed in Unixes since
before VMS
| existed. 
I have yet to see a version of "sum" that
understands object or
executable file syntax and skips the "noise"
stuff.

|	   Checksum has too many characters in the name .
Yes, but VMS allow you to abbreviate automatically to the
shortest
unique name.  Four characters (for top-level commands) is
guaranteed
to be sufficient at least among vendor-provided commands, so
"chec"
would always be safe.  In practice, I think "ch"
was probably enough,
beating out "sum".    Of
course, you could also abbreviate
option names to the shortest unique value, so ch/i would
almost
certainly have given you "checksum/image" in even
fewer characters
than a hypothetical "sum -i" option for Unix. 
 

							-- Jerry

| Greg.
| 
| 

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com
handling weak keys using random selection and CSPRNGs
user name
2006-10-14 03:22:00
> The only things that it usually passes as good are
for-purpose random
> number generators' or ciphers' outputs. Everything else
(including a
> terabyte of RC4 output, executables, zip archives,
jpegs, mpegs,
> mp3s, ...) that I've pointed it at, fails one or more
of the tests.

Have you tried removing the headers and trailing data?

> True random-looking-ness is hard to find... 

Since when? There are plenty of easy ways to generate it.
Many compressed 
files will also pass your randomness tests if you test only
the compressed 
data itself, not the whole files.

Ruptor 


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com
handling weak keys using random selection and CSPRNGs
user name
2006-10-14 23:15:44
At 5:22  +0200 2006/10/14, Marcos el Ruptor wrote:
>>The only things that it usually passes as good are
for-purpose random
>>number generators' or ciphers' outputs. Everything
else (including a
>>terabyte of RC4 output, executables, zip archives,
jpegs, mpegs,
>>mp3s, ...) that I've pointed it at, fails one or
more of the tests.
>
>Have you tried removing the headers and trailing data?

Not specifically, but see below.

>
>>True random-looking-ness is hard to find... 
>
>Since when? There are plenty of easy ways to generate
it. Many 
>compressed files will also pass your randomness tests if
you test 
>only the compressed data itself, not the whole files.

I don't think so. If you look at the data I quoted in the
email you 
quoted from, the difference in frequency between the most
frequent 
byte and least frequent byte was over 500 occurrences. I
doubt that 
the jpeg header alone could account for that, although I'll
give you 
that since the byte value in question was zero, it may have
something 
to do with it.

The jpeg header is more complicated than I want to take the
time to 
understand at the moment. So here; I took the smallest
meaningful 
jpeg I had lying around (taken from someone's low-res camera
in 
2002), and I dropped about the first half of the file,
keeping only 
the last 34k. Note that the very same troublesome statistics
show up.










































I attach the picture in case anyone wants to duplicate the 
statistics. I'm the ugly one on the right. I don't even know
who most 
of the other people are.

Now, you said "compressed files" and you might not
have meant 
pictures, but note that L-Z style compressed files don't
really have 
much in the way of headers. If the headers were a problem,
you'd 
expect longer files to bury any deviation in the noise, but
it 
doesn't. The longer the files I test the more certainly
non-random 
they are.

I stand by my statements.

Greg.
handling weak keys using random selection and CSPRNGs
user name
2006-10-16 15:22:24
> Now, you said "compressed files" and you
might not have meant
> pictures, but note that L-Z style compressed files
don't really have
> much in the way of headers. If the headers were a
problem, you'd
> expect longer files to bury any deviation in the noise,
but it
> doesn't. The longer the files I test the more certainly
non-random
> they are.
>
> I stand by my statements.
>
> Greg.

Hello, Greg!

I did not say anything about pictures. I only said that it's
not that hard 
to find a compression algorithm or a source of randomness or
a simple PRNG 
that will pass all kinds of randomness tests. You said it's
hard, I said it 
wasn't. Maybe you want to try testing something packed with
WinRK or Durilca 
for example. You could probably even test the whole files
packed with 
them...

Although I totally agree with you that JPEG or ZIP (Deflate)
or LZ 
compressed data could only pass randomness tests if the data
was random to 
begin with. But come on, such weak ancient algorithms hardly
qualify as 
randomness benchmarks. Modern decent compression algorithms
like those used 
in Stuffit or Allume reduce JPEGs by about 25% or so
(losslessly). No wonder 
your tests show a bias!

On the other hand, maybe you have an amazing brilliant
randomness test there 
that fails all the compressed files and makes diehard look
like a baby's 
rattle... If that is the case, do share! 

Ruptor 


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com
SC-based link encryption
user name
2007-01-05 20:22:19
On 01/05/2007 10:53 AM, Paul Hoffman wrote:

> You could take an IPsec stack and repurpose it down one
layer in the
> stack. At least that way you'll know the security
properties of what you
> create.

That is a Good Idea that can be used in a wide range of
situations.  Here is some additional detail:

This can be understood as follows:  Half of IPsec
"tunnel
mode" can be described as IPIP encapsulation layered on
top of "transport mode" which does the encryption
and
arranges for transport of the encrypted packets.

   The other half of IPsec is the SPDB, which is an
   important part of IPsec but is often underappreciated
   by non-experts.

So ... one obvious way forward is to do what might be
called L2sec (layer 2 security) in analogy to IPsec.
That is, do layer-2-in-IP encapsulation using GRE or
the like, and then layer that on top of IPsec transport
mode.

  Then you make some straightforward tweaks to the
  SPDB and you've something pretty nice.  As PH
  said, the security properties will be well known.

This may sound like overkill, but it is likely to be
/easier/ than anything else you can think of (not to
mention more secure and more richly featured).

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com
[1-9]

about | contact  Other archives ( Real Estate discussion Medical topics )