Re: - no reply

Alfred Peters

unread,

Dec 28, 2012, 1:55:11 PM12/28/12

to

Michael Jaritz

unread,

Dec 29, 2012, 7:41:37 AM12/29/12

to

Alfred Peters schrieb:

>Es schrieb einmal Alfred Peters:
>> Es schrieb einmal Michael Jaritz:
>>> Alfred Peters schrieb:
>
>>>> Du k�nntest h�chstens das Hash-Verfahren direkt aus dem Header der
>>>> Unterschrift auslesen. Du m�sstest nur[TM] die ersten Bytes dekodieren.
>>>>
>>>> [1] -> [2]/[3] -> [4]
>
>
>>>> [1] <http://tools.ietf.org/html/rfc4880#section-4.2>
>>>> [2] <http://tools.ietf.org/html/rfc4880#section-5.2.2>
>>>> [3] <http://tools.ietf.org/html/rfc4880#section-5.2.3>
>>>> [4] <http://tools.ietf.org/html/rfc4880#section-9.4>
>>>
>>> H�rt sich interssant an. Wie s�he das in hsc aus ;-?
>>
>> Viel zu aufwendig. *d&r*

Dieser Satz hatte schon meinen Ehrgeiz geweckt.

Nun ist der Ehrgeiz erstmal wieder weg ;-) Nee, im Ernst: An Deiner
L�sung merke ich das Du programmieren kannst - nicht so ein
Gelegenheitsst�mper wie ich. Meine L�sung w�re wesentlich l�nger
(spaghetticodem��iger) geworden, da ich mangels Verst�ndnis �berhaupt
nicht an das bin�re UND gedacht h�tte.

>| varset $headerLength, $packetLength, 0
>| if( 0=($PacketTag & 0x40) )

Und hier
| Bit 6 -- New packet format if set

Bei "$headerLength = ($PacketTag & 0x03)" h�rt es bei mir auf. Was tut
das?

Hast Du eigentlich schon mal ein "New packet format" gesehen?

Ich werde mich erst n�chstes Jahr wieder damit besch�ftigen k�nnen, aber
falls jemand testen will:

|#SHA1 #Message-ID: <9m6159x...@goaway.wombat.san-francisco.ca.us> #Newsgroups: comp.unix.shell
|#SHA1 #Message-ID: <cmsg-20121201080403$17...@vulture.killfile.org> #Newsgroups: news.admin.hierarchies,us.config
|#RIPEMD160 #Message-ID: <271212.142...@wolfgang-bauer.at> #Newsgroups: de.test
|#SHA256 #Message-ID: <271212.134...@posting-with.my-fqdn.de> #Newsgroups: de.test
|#SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control

Guten Rutsch und ein frohes neues Jahr
Michael

Alfred Peters

unread,

Dec 29, 2012, 12:05:23 PM12/29/12

to

Es schrieb einmal Michael Jaritz:
> Alfred Peters schrieb:
>> Es schrieb einmal Alfred Peters:

>>> Viel zu aufwendig. *d&r*
>
> Dieser Satz hatte schon meinen Ehrgeiz geweckt.

Meinen auch. :-)

>>| if( 0=($PacketTag & 0x80) )

> Hier verarbeitest Du

>| Bit 7 -- Always one

>>| if( 0=($PacketTag & 0x40) )
>
> Und hier
>| Bit 6 -- New packet format if set

Korrekt.

> Bei "$headerLength = ($PacketTag & 0x03)" hört es bei mir auf. Was tut
> das?

Das maskiert die Bits 1 und 0 aus:

| Old format packets contain:
|
| Bits 5-2 -- packet tag
| Bits 1-0 -- length-type

Also den 'length-type'.

"($PacketTag & 0x3C) >> 2" maskiert dann entsprechend die Bits 2 bis 5 und
schiebt sie zwei Bits nach rechts.

> Hast Du eigentlich schon mal ein "New packet format" gesehen?

Nein. Mein Hamster hat 12983 Artikel mit X-PGP-Sig:-Header. Keiner davon
hat das neue Format.

Das ist auch kein Wunder:

# PGP 2.6.x only uses old format packets. Thus, software that
# interoperates with those versions of PGP must only use old format
# packets.

Aber man weiß ja nie. :-)

> Guten Rutsch und ein frohes neues Jahr

dito
Alfred
--
12993.8

Reinhard Irmer

unread,

Dec 29, 2012, 12:31:47 PM12/29/12

to

Hallo *Michael*,

*_<(o¿o)>Michael Jaritz_* schrieb:
[...]
> Ich werde mich erst nächstes Jahr wieder damit beschäftigen können, aber
> falls jemand testen will:

ich hab den code von Alfred einfach mal per c/p in das autoverify.hsc reinkopiert, ein testposting losgelassen um zu schauen was passiert:
Das hier:
Auszug aus dem Hamsterlog:
2012.12.29 18:14:28 u1 {af0} > <291212.181...@posting-with.my-fqdn.de> - de.test:9183
2012.12.29 18:14:28 u1 {af0} > Hashverfahren laut Hash: MD5
2012.12.29 18:14:29 u1 {af0} > Signatur vom 29.12.2012 18:13:47 Westeuropäische Normalzeit mittels RSA-Schlüssel ID 780626D0
Korrekte Signatur von "Reinhard Irmer <fr...@spamfence.net>"
2012.12.29 18:14:29 D {af0} Erzeuge Gruppendatei für: hamster.answers2mypostings
2012.12.29 18:14:30 Sys {af0} {script AutoVerify.hsc} Ende
2012.12.29 18:14:30 Sys {210} Skript C:\Programme\hamster\AutoVerify.hsc beendet.

Das script läuft ohne Fehlermeldung durch und wie Du siehst, wird auch die entsprechende Zeile geschrieben. Im posting selbst sehe ich keine Veränderung.

Viele Gruesse
Rεìñhατδ

--
.----[ *3 weisse Bi-hirken* ]-----.
[ in meiner Heimat steh'n und auf ]
[ dem Classic- Hamster 2.1.0.1531 ]
'---------------------------------'
Downloads: http://tinyurl.com/yjcdmlx

Michael Jaritz

unread,

Dec 31, 2012, 7:08:27 AM12/31/12

to

Alfred Peters schrieb:

>Es schrieb einmal Michael Jaritz:
>> Alfred Peters schrieb:
>>> Es schrieb einmal Alfred Peters:

>> Bei "$headerLength = ($PacketTag & 0x03)" h�rt es bei mir auf. Was tut

>> das?
>
>Das maskiert die Bits 1 und 0 aus:
>
>| Old format packets contain:
>|
>| Bits 5-2 -- packet tag
>| Bits 1-0 -- length-type
>
>Also den 'length-type'.
>
>"($PacketTag & 0x3C) >> 2" maskiert dann entsprechend die Bits 2 bis 5 und
>schiebt sie zwei Bits nach rechts.

Bin doch noch dieses Jahr dazu gekommen.
Ok, die ganze Bit-Maskierung und Verschieberei habe ich verstanden.
Haken tut es jetzt noch ganz am Anfang:

Die Liste $lPGP sieht ja zB so aus
|$lPGP[0]="GnuPG_v1.4.10_(MingW32) Subject,Newsgroups,User-Agent,Message-ID,Date,From"
|$lPGP[1]=" iQEVAwUBUOA4nwv4WEO4ZQzEAQEpKAf/Zj78nu3PCfWl217KNKqMYGKeFujeHz/B"
|$lPGP[2]=" INRFfo2Gfmr7EXvRSGkaTlYH9TLUOVDiwd8t9Y6ED0Qds7MBlCNTwAAP6w0Tvejv"
|$lPGP[3]=" KWLzj2kUNaEjdS4QToSUeuwP+R6B+tM2k5YWlyOvXz+buXWaj+dppSTrQXPFIYPV"
|$lPGP[4]=" sdcow3Cahy7aFRr5O8S456tTNLfBWFALewLo6vwXPYJdNiVpkS1QwnvaxjdFWek7"
|$lPGP[5]=" nPNvqaBcxDQcUnE05gMyax2aOdxONYc+8kJ+4a5cGWPHGYhkMFzLDzWfCNDqPACM"
|$lPGP[6]=" ZaLvKSCg0wZpmHNzr6hMQ0tJcXEJrms15Qoacg84xKnUF6EdYtQ5bg=="
|$lPGP[7]=" =KoJF"

Wie k�nnten denn in $lPGP[1] noch
"^(Version|Comment|MessageID|Hash|Charset):\s" auftauchen? Comment
eventuell weil jemand nicht mit " --no-comments" signiert hat, aber zB
MessageID? Hast Du vielleicht eine MID in der die ben�tigte Info nicht
in $lPGP[1] sondern in $lPGP[2] steht?

Michael

--
np: Barclay James Harvest / Octoberon - Suicide?

Steffens Hamsterhilfe: <http://speravir.website.org/files/hamsterhilfe/>

Alfred Peters

unread,

Dec 31, 2012, 9:38:47 AM12/31/12

to

Es schrieb einmal Michael Jaritz:

> Wie k�nnten denn in $lPGP[1] noch
> "^(Version|Comment|MessageID|Hash|Charset):\s" auftauchen?

Im Header Vermutlich nicht. Daf�r w�rde dann auch das FoldingWhiteSpace
Fehlern. Im Body aber schon.

> Comment
> eventuell weil jemand nicht mit " --no-comments" signiert hat,

Im Body kommt das �fter vor. Selten auch mal 'charset'. Es kann aber nicht
schaden, auf alle erlaubten Header[1] zu testen.

In den Artikel-Header k�nnen die Zeilen eigentlich gar nicht aufgenommen
werden, denn vor der eigentlichen Unterschrift steht noch eine Leerzeile.
Und in einem Artikle-Header sind leeren gefalteten Zeilen erlaubt.

> aber zB
> MessageID? Hast Du vielleicht eine MID in der die ben�tigte Info nicht
> in $lPGP[1] sondern in $lPGP[2] steht?

Nein.

Alfred

[1] <http://tools.ietf.org/html/rfc4880#section-6.2>
--
12999.0

Karsten Düsterloh

unread,

Jan 2, 2013, 6:34:26 PM1/2/13

to

Michael Jaritz aber hob zu reden an und schrieb:

> falls jemand testen will:
>
> |#SHA1 #Message-ID: <9m6159x...@goaway.wombat.san-francisco.ca.us> #Newsgroups: comp.unix.shell
> |#SHA1 #Message-ID: <cmsg-20121201080403$17...@vulture.killfile.org> #Newsgroups: news.admin.hierarchies,us.config
> |#RIPEMD160 #Message-ID: <271212.142...@wolfgang-bauer.at> #Newsgroups: de.test
> |#SHA256 #Message-ID: <271212.134...@posting-with.my-fqdn.de> #Newsgroups: de.test
> |#SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control

Danke, kommt mir sehr gelegen (auch ohne Hamster). ;-)

Karsten
--
Freiheit stirbt | Fsayannes SF&F-Bibliothek:
Mit Sicherheit | http://fsayanne.tprac.de/

Karsten Düsterloh

unread,

Jan 2, 2013, 6:55:57 PM1/2/13

to

Michael Jaritz aber hob zu reden an und schrieb:

> |#SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control

Hm, ich sehe hier aber auch nur MD5, nicht SHA224?

Karsten Düsterloh

unread,

Jan 2, 2013, 7:34:39 PM1/2/13

to

Karsten Düsterloh aber hob zu reden an und schrieb:

> Michael Jaritz aber hob zu reden an und schrieb:
>> |#SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control
>
> Hm, ich sehe hier aber auch nur MD5, nicht SHA224?

Noch mehr hm:
Sehen diese Signaturen in #control

<rmgroup-grisbi.pa...@news.grisbi.org>
<rmgroup-fr.comp.os.mac-...@usenet-fr.news.eu.org>

für euch korrekt aus?

Wolfgang Bauer

unread,

Jan 3, 2013, 3:52:37 AM1/3/13

to

>Absender:Karsten Düsterloh

SHA1
Message-ID: <9m6159x...@goaway.wombat.san-francisco.ca.us> Newsgroups: comp.unix.shell
Cancel-Lock: sha1:b88LN3arF3/dvuMrgrzQ+X3vsI4=
~~~~~~~~~~~~~^^^^
X-PGP-CHECK: Bad Sig :-(

SHA1
Message-ID: <cmsg-20121201080403$17...@vulture.killfile.org> #Newsgroups: news.admin.hierarchies,us.config
kein HASH im Header
X-PGP-CHECK: Bad Sig :-(

RIPEMD160
Message-ID: <271212.142...@wolfgang-bauer.at> #Newsgroups: de.test
X-PGP-CHECK: Good Sig :-)

SHA256
Message-ID: <271212.134...@posting-with.my-fqdn.de> #Newsgroups: de.test
X-PGP-CHECK: Good Sig :-)

SHA224
Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control
kein HASH im Header
X-PGP-CHECK: Bad Sig :-(

Die anderen beiden.

<rmgroup-grisbi.pa...@news.grisbi.org>
<rmgroup-fr.comp.os.mac-...@usenet-fr.news.eu.org>
kein HASH im Header
X-PGP-CHECK: Bad Sig :-(

Verifiziert mit XGpgSig.exe von Remo Müller.

Alfred Peters

unread,

Jan 3, 2013, 1:33:32 PM1/3/13

to

Es schrieb einmal Karsten Düsterloh:

> Michael Jaritz aber hob zu reden an und schrieb:

>>|# SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control

>
> Hm, ich sehe hier aber auch nur MD5, nicht SHA224?

Ja. Keine Ahnung, wie Michael auf SHA224 kommt.

Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.

Im Header steht aber ein hinweis, wie es gehen soll:

X-Info: ftp://ftp.isc.org/pub/pgpcontrol/README
ftp://ftp.isc.org/pub/pgpcontrol/README.html

Das Perl-Skript bekomme ich aber nicht zum laufen.

Wenn ich das richtig sehe, speichert das Skript die Nachricht und die
Signatur in getrennte Dateien: $filename und $filename.asc

Das sollte noch machbar sein. Aber über das Format bin ich mir nicht im
Klaren. Vor allem scheint es Linux Zeilenenden zu verwenden:

| # Remove NNTP encoding
| s/^\.\./\./;
| s/\r\n$/\n/;

Es wäre interessant, wie die Dateien tatsächlich aussehen.

Alfred
--
13007.7

Alfred Peters

unread,

Jan 3, 2013, 1:44:05 PM1/3/13

to

Es schrieb einmal Karsten D�sterloh:

> Noch mehr hm:
> Sehen diese Signaturen in #control
>
> <rmgroup-grisbi.pa...@news.grisbi.org>

MD5 Bad

> <rmgroup-fr.comp.os.mac-...@usenet-fr.news.eu.org>

SHA1 Bad

> f�r euch korrekt aus?

Und wieder der Hinweis im Header auf:

<ftp://ftp.isc.org/pub/pgpcontrol/README.html>

Alfred
--
13007.7

Alfred Peters

unread,

Jan 3, 2013, 2:29:45 PM1/3/13

to

Es schrieb einmal Alfred Peters:

> Das sollte noch machbar sein. Aber über das Format bin ich mir nicht im
> Klaren. Vor allem scheint es Linux Zeilenenden zu verwenden:
>
>| # Remove NNTP encoding
>| s/^\.\./\./;
>| s/\r\n$/\n/;

Nee, ich denke nicht.

> Es wäre interessant, wie die Dateien tatsächlich aussehen.

Steht doch hier beschrieben:

<ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>

Sieht genauso aus, wie beim Hamster-Skript.

Und nachdem ich die Zeilenenden aus dem Beispiel[1] nach CRLF
gewandelt habe, bekomme ich dafür auch mit dem Hamster-Skript ein GOOD-SIG.

Alfred

[1] <ftp://ftp.isc.org/pub/pgpcontrol/sample.control>
--
13007.8

Karsten Düsterloh

unread,

Jan 3, 2013, 4:46:34 PM1/3/13

to

Alfred Peters aber hob zu reden an und schrieb:

> Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.

Das funktioniert hier zwar,

> Vor allem scheint es Linux Zeilenenden zu verwenden:

allerdings nutze ich Linux.

Andererseits läuft meine Verifikation per Enigmail innerhalb meines
SeaMonkeys, was wiederum auf ein lokal installiertes gpg zurückgreift.
Hamster oder Delphi sind also hier nicht beteiligt. ^_^

Alfred Peters

unread,

Jan 3, 2013, 6:32:57 PM1/3/13

to

Es schrieb einmal Karsten Düsterloh:

> Alfred Peters aber hob zu reden an und schrieb:
>> Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.
>
> Das funktioniert hier zwar,

:-O

>> Vor allem scheint es Linux Zeilenenden zu verwenden:
>
> allerdings nutze ich Linux.
>
> Andererseits läuft meine Verifikation per Enigmail innerhalb meines
> SeaMonkeys, was wiederum auf ein lokal installiertes gpg zurückgreift.

Kannst Du das Temporäre File exportieren?
Wie sieht der Aufruf von gpg (Parameter) aus?

> Hamster oder Delphi sind also hier nicht beteiligt. ^_^

Die dürften unschuldig sein. Ich habe den Artikel noch einmal direkt
geholt und das File per Hand aufgebaut. Immer noch Bad-Sig. :-(

Wenn Du magst, kannst Du das File mal direkt an dein gpg verfüttern:

* watcom_a.msg (885 bytes) hosted on Dropbox: http://db.tt/Z2H2NGTD

Alfred
--
13008.2

Karsten Düsterloh

unread,

Jan 3, 2013, 7:03:22 PM1/3/13

to

Alfred Peters aber hob zu reden an und schrieb:
> Es schrieb einmal Karsten Düsterloh:
>> Alfred Peters aber hob zu reden an und schrieb:
>>> Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.
>>
>> Das funktioniert hier zwar,
>
> :-O

Ah, sorry, Mißverständnis auf meiner Seite.
Ich meinte, daß ich bei MD5 keinen Sig-Alg-Mismatch bekomme.
Da Mozilla aber den
Content-Type: application/news-groupinfo; charset=ISO-8859-1
nicht versteht, kann ich den Artikel nicht testen.
Der Zusammenbau von Hand führt jedenfalls zu keiner GOOD SIG.
(Unabhängig vom Zeilenumbruch LR oder CRLF.)

> Kannst Du das Temporäre File exportieren?

Schon, ist hier aber kaputt, da Mozilla den Rumpfinhalt nicht findet.

> Wenn Du magst, kannst Du das File mal direkt an dein gpg verfüttern:
>
> * watcom_a.msg (885 bytes) hosted on Dropbox: http://db.tt/Z2H2NGTD

Nein, das mag mein gpg auch nicht.

Meinem gpg sind im übrigen die Zeilenumbrucharten (CRLF vs. LF) egal,
eine gute Sig wird dadurch nicht behindert.

Alfred Peters

unread,

Jan 4, 2013, 4:11:01 PM1/4/13

to

Es schrieb einmal Alfred Peters:

> Es schrieb einmal Karsten Düsterloh:
>> Michael Jaritz aber hob zu reden an und schrieb:
>>>|# SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control

> Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.

> Im Header steht aber ein hinweis, wie es gehen soll:
>
> X-Info: ftp://ftp.isc.org/pub/pgpcontrol/README
> ftp://ftp.isc.org/pub/pgpcontrol/README.html

Ich habe noch ein paar andere Artikel mit diesem Hinweis getestet. Einige
liefern durchaus ein GOOD-SIG[1] andere nicht.

Aufgefallen ist mir im 'signcontrol'-Skript:

|# headers to sign. Sender is included because non-PGP authentication uses
|# it. The following should always be signed:
|# Subject -- some older news systems use it to identify the control action.
|# Control -- most news systems use this to determine what to do.
|# Message-ID -- guards against replay attacks.
|# Date -- guards against replay attacks.
|# From -- used by news systems as part of authenticating the message.
|# Sender -- used by news systems as part of authenticating the message.
| @signheaders = ('Subject', 'Control', 'Message-ID', 'Date', 'From', 'Sender');
|
|# headers to remove from real headers of final message.
|# If it is a signed header, it is signed with an empty value.
|# set to () if you do not want any headers removed.
| @ignoreheaders = ('Sender');

Das heißt, wenn ich nicht irre, dass der Sender-Header als leerer Header
mit signiert wird.

Aber auch Tests mit leerem oder ganz ohne Header waren nicht erfolgreich.

Auffällig ist, dass in der Tat die meisten der BAD-SIG-Artikel einen
Sender-Header haben.

GOOD-SIG-Artikel mit Sender-Header haben ihn entweder doch mit Inhalt[2]
oder gar nicht signiert.

Alfred
[1] <1351836...@news.sztaki.hu>
[2] <12913154...@cmsgs.netzverwaltung.net>
--
13010.7

Alfred Peters

unread,

Jan 4, 2013, 4:02:32 PM1/4/13

to

Es schrieb einmal Karsten Düsterloh:
> Alfred Peters aber hob zu reden an und schrieb:
>> Es schrieb einmal Karsten Düsterloh:
>>> Alfred Peters aber hob zu reden an und schrieb:
>>>> Der Artikel lässt sich hier aber auch mit MD5 nicht verifizieren.
>>> Das funktioniert hier zwar,
>> :-O
>
> Ah, sorry, Mißverständnis auf meiner Seite.

> Der Zusammenbau von Hand führt jedenfalls zu keiner GOOD SIG.

Gut, dann ist mein Weltbild wieder in Ordnung. ;-)

> (Unabhängig vom Zeilenumbruch LR oder CRLF.)

> Meinem gpg sind im übrigen die Zeilenumbrucharten (CRLF vs. LF) egal,
> eine gute Sig wird dadurch nicht behindert.

Nur wenn '--textmode' aktiv war/ist. Damit werden die Zeilenenden
automatisch zu CRLF umgewandelt.

Alfred
--
13010.7

Karsten Düsterloh

unread,

Jan 5, 2013, 2:31:48 AM1/5/13

to

Alfred Peters aber hob zu reden an und schrieb:

> |# headers to remove from real headers of final message.
> |# If it is a signed header, it is signed with an empty value.
> |# set to () if you do not want any headers removed.
> | @ignoreheaders = ('Sender');
>
> Das heißt, wenn ich nicht irre, dass der Sender-Header als leerer Header
> mit signiert wird.
>
> Aber auch Tests mit leerem oder ganz ohne Header waren nicht erfolgreich.

In pgpcontrol steht irgendwo, daß zu signierende nichtvorhandene/leere
Headerzeilen trotzdem eine Zeile Headername + Doppelpunkt + Leerzeichen
im zu signierenden Block bilden müssen.
Ist das das, was du probiert hast?
(Kann ich gerade hier auf dem Mac nicht testen.)

Alfred Peters

unread,

Jan 5, 2013, 8:53:34 AM1/5/13

to

Es schrieb einmal Karsten D�sterloh:

> Alfred Peters aber hob zu reden an und schrieb:
>>|# headers to remove from real headers of final message.
>>|# If it is a signed header, it is signed with an empty value.
>>|# set to () if you do not want any headers removed.
>>| @ignoreheaders = ('Sender');
>>

>> Das hei�t, wenn ich nicht irre, dass der Sender-Header als leerer Header

>> mit signiert wird.
>>
>> Aber auch Tests mit leerem oder ganz ohne Header waren nicht erfolgreich.
>

> In pgpcontrol steht irgendwo, da� zu signierende nichtvorhandene/leere

> Headerzeilen trotzdem eine Zeile Headername + Doppelpunkt + Leerzeichen

> im zu signierenden Block bilden m�ssen.

> Ist das das, was du probiert hast?

= 'leerer Header' Ja, habe ich.

Das Leerzeichen am ende sollte keinen Einfluss auf die Signatur haben.
Zumindest ist das so bei GOOD-SIG-Artikeln. gpg entfernt SPACES am ende
der Zeile vor dem signieren/verifizieren. Aber ist das auch bei diesem
Artikel passiert?

Aber auch varianten (eine LZ f�r die Sender-Zeile / ohne die Zeile) habe
ich probiert.

Ich habe aber bislang keinen einzigen Fall gefunden, bei dem der Artikel
einen Sender-Header hat, die Signatur aber mit einem leeren Sender korrekt
ist. Umgekehrt schon. Da kocht also wohl jeder sein eigenes S�ppchen.

Einzelne Artikel sind sogar mit SHA1 gehasht. Daf�r muss am Anfang des
pgp-Bodys die 'Hash: SHA1' Zeile stehen (bei MD5 ist sie optional). Mit
der Zeile liefert das Hamster-Skript hier ein GOOD-SIG. Da das
pgpcontrol-Skript in seiner Urform die Zeile aber gar nicht erzeugt,
d�rfte es dort niemals ein GOOD-SIG geben.

Hier noch weiter rumzuraten halte ich f�r wenig erfolgversprechend. Wenn
Du es genauer wissen m�chtest, sollten wir uns an die experten in
d.c.s.newsserver wenden. Dort habe ich zumindest einige Threads zum
pgpcontrol gesehen. Oder an den Autor des Artikels. Der m�sste doch
wissen, was er signiert hat. *veg*

Alfred
--
13012.6

Michael Jaritz

unread,

Jan 5, 2013, 3:11:42 PM1/5/13

to

Alfred Peters schrieb:

>Es schrieb einmal Karsten D�sterloh:

>> Michael Jaritz aber hob zu reden an und schrieb:
>>>|# SHA224 #Message-ID: <newgroup-openwatcom.use...@newsfeed.cmeerw.net> #control
>>
>> Hm, ich sehe hier aber auch nur MD5, nicht SHA224?
>
>Ja. Keine Ahnung, wie Michael auf SHA224 kommt.

Uuups, das ist ganz leicht durch Dummheit zu erkl�ren ;-)

Ich habe einfach die tempor�ren Dateien (die wurden bei mir nicht
gel�scht) per "egrep '^Hash: ' | fgrep -v MD5" durchgeschaut. Nicht
bedacht hatte ich dabei, das in allen Dateien in denen keine
Verifizierung erfolgreich war als letzter Versuch SHA224 stand.

Michael

--
np: Beatles / Let It Be - I've Got A Feeling

Steffens Hamsterhilfe: <http://speravir.website.org/files/hamsterhilfe/>

Karsten Düsterloh

unread,

Jan 6, 2013, 3:58:56 PM1/6/13

to

Alfred Peters aber hob zu reden an und schrieb:

> Ich habe aber bislang keinen einzigen Fall gefunden, bei dem der
> Artikel einen Sender-Header hat, die Signatur aber mit einem leeren
> Sender korrekt ist. Umgekehrt schon. Da kocht also wohl jeder sein

> eigenes Süppchen.

Das kommt halt davon, wenn man keinen vernünftig Standard hat. :-/

> Einzelne Artikel sind sogar mit SHA1 gehasht. Dafür muss am Anfang

> des pgp-Bodys die 'Hash: SHA1' Zeile stehen (bei MD5 ist sie
> optional). Mit der Zeile liefert das Hamster-Skript hier ein
> GOOD-SIG. Da das pgpcontrol-Skript in seiner Urform die Zeile aber

> gar nicht erzeugt, dürfte es dort niemals ein GOOD-SIG geben.

Ja, sehe ich auch so.
Wobei die Anzahl der Hash:-Header-Zeilen im Armorblock ja nach
RfC4880/Kapitel 7 egal ist und keinenEinfluß auf die eigentliche
Signatur hat.

> Hier noch weiter rumzuraten halte ich für wenig erfolgversprechend.

Yep. *nick*

> Wenn Du es genauer wissen möchtest, sollten wir uns an die experten

> in d.c.s.newsserver wenden. Dort habe ich zumindest einige Threads
> zum pgpcontrol gesehen.

Oder comp.security.pgp.* — werde ich auch tun, sobald ich mir sicher
(genug) bin, keinen allzugroben Unfug (miß)verstanden zu haben. ^_^

> Oder an den Autor des Artikels. Der müsste doch wissen, was er
> signiert hat. *veg*

Hehe, theoretisch. Oder führt einfach ein Script aus, daß er nicht
versteht …

Alfred Peters

unread,

Jan 7, 2013, 2:18:39 PM1/7/13

to

Es schrieb einmal Karsten D�sterloh:

> Alfred Peters aber hob zu reden an und schrieb:

>> GOOD-SIG. Da das pgpcontrol-Skript in seiner Urform die Zeile aber

>> gar nicht erzeugt, d�rfte es dort niemals ein GOOD-SIG geben.

>
> Ja, sehe ich auch so.
> Wobei die Anzahl der Hash:-Header-Zeilen im Armorblock ja nach

> RfC4880/Kapitel 7 egal ist und keinenEinflu� auf die eigentliche
> Signatur hat.

<http://tools.ietf.org/html/rfc2440#section-14>
14. Implementation Nits
| [...]
| * In a clear-signed signature, PGP 5.0 will figure out the correct
| hash algorithm if there is no "Hash:" header, but it will reject
| a mismatch between the header and the actual algorithm used. The
| "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
| rejects the "Hash:" header and assumes MD5. There are a number of
| enhanced variants of PGP 2.6.x that have been modified for SHA-1
| signatures.

Alfred
--
13018.7

Alfred Peters

unread,

Jan 7, 2013, 3:26:00 PM1/7/13

to

Es schrieb einmal Karsten D�sterloh:

> Wobei die Anzahl der Hash:-Header-Zeilen im Armorblock ja nach

> RfC4880/Kapitel 7 egal ist und keinenEinflu� auf die eigentliche
> Signatur hat.

Ja, stimmt auff�llig. :-D

| gpg: ASCII-H�lle: BEGIN PGP SIGNED MESSAGE
| gpg: ASCII-H�lle: Hash: MD5,SHA1,RIPEMD160,SHA256,SHA384,SHA512,SHA224
[...]
| gpg: Korrekte Signatur von "news.cs.nctu.edu.tw"
[...]
| gpg: Textmodus Signatur, Hashmethode "SHA1"

Wer ist eigentlich auf die Idee gekommen, dass wir das Hash-Verfahren
vorher br�uchten? *g*

Al-Skywalker-fred
--
13018.8

Karsten Düsterloh

unread,

Jan 7, 2013, 3:50:23 PM1/7/13

to

Alfred Peters aber hob zu reden an und schrieb:

> | gpg: ASCII-Hülle: Hash: MD5,SHA1,RIPEMD160,SHA256,SHA384,SHA512,SHA224

> [...]
> | gpg: Korrekte Signatur von "news.cs.nctu.edu.tw"
> [...]
> | gpg: Textmodus Signatur, Hashmethode "SHA1"

LOL.

> Wer ist eigentlich auf die Idee gekommen, dass wir das Hash-Verfahren

> vorher bräuchten? *g*

Naja, obiges funktioniert natürlich nur, wenn man die Codes der
Hashverfahren alle kennt. Aber das muß ich ja auch, wenn ich den Header
der Sig auflöse, um an das Verfahren zu kommen — insofern ist deine Idee
oben einfach nur genial. ;-)

Im Zweifelsfall kann man einfach die Hash:-Zeile von
$ ggp --version
…
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
direkt übernehmen.

Michael Jaritz

unread,

Jan 7, 2013, 4:23:16 PM1/7/13

to

Alfred Peters schrieb:

Ich hab es so aus alten Scripten �bernommen. Auf die Idee den
entsprechenden RFC zu lesen bin ich beim Scripten nie gekommen.

Diese neue Erkenntnis vereinfacht so einiges... Das Deine sub
getAlgoFormHash trotz allem sehr hilfreich war - schon als gutes
Beispiel f�r Bitmaskierung in hsc - muss trotzdem erw�hnt werden.

>Al-Skywalker-fred

Mic<Quick'n'Dirty>hael

--
np: Jethro Tull / Stand Up - We Used to Know

Steffens Hamsterhilfe: <http://speravir.website.org/files/hamsterhilfe/>

Karsten Düsterloh

unread,

Jan 7, 2013, 5:55:45 PM1/7/13

to

Alfred Peters aber hob zu reden an und schrieb:

> Im Header steht aber ein hinweis, wie es gehen soll:
>
> X-Info: ftp://ftp.isc.org/pub/pgpcontrol/README
> ftp://ftp.isc.org/pub/pgpcontrol/README.html
>
> Das Perl-Skript bekomme ich aber nicht zum laufen.

Doch, das funktioniert hier, nachdem ich ihm den Pfad zum gpgv
beigebracht habe (Zeile ~125). Au�erdem sollte man es mit -test
aufrufen, damit man was sieht:
./pgpverify -test < message.eml
wobei message.eml eine Mail mit X-PGP-Sig ist.

Das Skript pr�ft die Signatur *detached*, wobei das zB f�r
<rmgroup-fr.comp.os.mac-...@usenet-fr.news.eu.org>
"good" liefert. Meine Basteleien, diese Sig "non-detached" als
clearsign-Sig zu verifizieren, sind bis jetzt allerdings fehlgeschlagen.

Die allwissende M�llhalde mag mir momentan auch nicht weiterhelfen.
Vielleicht kann ich ja anstelle der "Inline-Signatur" eine
PGP/MIME-Signatur simulieren und die dann von Enigmail verifizieren lassen.

> Wenn ich das richtig sehe, speichert das Skript die Nachricht und die
> Signatur in getrennte Dateien: $filename und $filename.asc
>

> Das sollte noch machbar sein. Aber �ber das Format bin ich mir nicht im

> Klaren. Vor allem scheint es Linux Zeilenenden zu verwenden:

Um die Zeilenendenformat sollte sich das gpg k�mmern.

> Es w�re interessant, wie die Dateien tats�chlich aussehen.

Zeile 522 auskommentieren, dann bleiben die Dateien /tmp/pgp* erhalten:
# unlink ($filename, "$filename.asc");

Hat mir allerdings nicht geholfen.

Alfred Peters

unread,

Jan 12, 2013, 1:14:06 PM1/12/13

to

Es schrieb einmal Karsten D�sterloh:

> Alfred Peters aber hob zu reden an und schrieb:
>> Im Header steht aber ein hinweis, wie es gehen soll:
>>
>> X-Info: ftp://ftp.isc.org/pub/pgpcontrol/README
>> ftp://ftp.isc.org/pub/pgpcontrol/README.html
>>
>> Das Perl-Skript bekomme ich aber nicht zum laufen.

> Das Skript pr�ft die Signatur *detached*, wobei das zB f�r
> <rmgroup-fr.comp.os.mac-...@usenet-fr.news.eu.org>
> "good" liefert.

Das habe ich inzwischen auch hinbekommen.

[...]

> Um die Zeilenendenformat sollte sich das gpg k�mmern.

Nur wenn mit --clearsign oder --textmode signiert wurde. Das ist aber bei
obigem Artikel nicht der Fall:

| gpg: Bin�re Signatur, Hashmethode "SHA1"

Und in diesem Fall muss es LF sein. <seufz />

Allerdings sollte man dann beim Verify auch den '--textmode'-Parameter weg
lassen. <seufz />

Au�erdem sind daduch eigentlich auch Leerzeichen am Zeilenende wichtig.
Nur wegen des:

| # Write the message to the PGP process. Strip all trailing whitespace
| # for compatibility with older pgpverify and attached signature
| # verification.

m�ssen sie manuell entfernt werden. Insbesondere gilt das f�r den leeren
Sender-Header. <seufz />

Auch die "cmsg checkgroups openwatcom"-Artikel lassen sich so �berpr�fen.

Nat�rlich mit der Adresse im Sender. <seufz />

Nur der 'newgroup'-Artikel[2] des gleichen Autors weigert sich immer noch
beharrlich.

Alfred

[1] <checkgroups-open...@newsfeed.cmeerw.net>
[2] <newgroup-openwatcom.use...@newsfeed.cmeerw.net>
--
13032.3

Re: - no reply - ignore

Alfred Peters

Michael Jaritz

Alfred Peters

Reinhard Irmer

Michael Jaritz

Alfred Peters

Karsten Düsterloh

Karsten Düsterloh

Karsten Düsterloh

Wolfgang Bauer

Alfred Peters

Alfred Peters

Alfred Peters

Karsten Düsterloh

Alfred Peters

Karsten Düsterloh

Alfred Peters

Alfred Peters

Karsten Düsterloh

Alfred Peters

Michael Jaritz

Karsten Düsterloh

Alfred Peters

Alfred Peters

Karsten Düsterloh

Michael Jaritz

Karsten Düsterloh

Alfred Peters