mikrocontroller.net

Forum: Offtopic 0xFFFF als CRC-16 möglich?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas H. (andario)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo zusammen,

Wenn ich über sagen wir mal 20 Byte eine CRC-16 (CCITT, Polynom 0x1021, 
Startwert 0xFFFF) rechne, ist es dann überhaupt möglich, dass als CRC 
0xFFFF herauskommt?
Ich vermute "nein", aber warum wäre das so? Und falls "nein" falsch ist 
- welche 20 Byte wären das?

Zu dieser Frage habe ich leider keine Antwort bei google gefunden.
Vielleicht weiß hier jemand was darüber...

Danke,
Andario

von Joggel E. (jetztnicht)


Bewertung
-2 lesenswert
nicht lesenswert
Und weshalb nicht ? Eigentlich muesste irgend eine Zahl moeglich sein.
Ich denke, schon nach 2 bytes muesste irgend eine Zahl als CRC moeglich 
sein.

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
-1 lesenswert
nicht lesenswert
Ändere einfach mal ein Bit ab, dann muss was anderes bei rauskommen

von Andreas H. (andario)


Bewertung
-1 lesenswert
nicht lesenswert
Hi, dass was anderes rauskommt, wenn ich ein bit ändere ist schon klar. 
Das ist ja der Sinn hinter der CRC.

Vielleicht nochmal zur Erklärung, worauf ich hinaus will:
Wir haben ein System mit 2 Teilnehmern.
A sendet Parameter (ca. 20 Byte) an B.
B macht damit etwas und rechnet zur Kontrolle über die tatsächlich 
verwendeten Parameter eine CRC. Diese soll zur Gegenprüfung wieder an A 
gesendet werden.
Falls B einen Fehler bei seiner Aktion festgestellt hat, soll 
stattdessen 0xFFFF übermittelt werden, damit A weiß, dass etwas schief 
gegangen ist.

Deshalb die Frage, ob es eine Kombination von 20 Byte gibt, deren CRC 
mit dem gegebenen Polynom und Startwert 0xFFFF geben kann.
Wie würde ich diese Kombination finden?

Grüße,
Andario

von Frank B. (frank501)


Bewertung
1 lesenswert
nicht lesenswert
Warum sollte B die CRC zurücksenden?
Sinnvoller wäre es, wenn A diese berechnet und gleich mit sendet, dann 
weiß B, ob die Parameter richtig angekommen sind. Sollte er dabei einen 
Fehler feststellen, sendet er einen eigenen Status zurück, der auch 
beinhalten kann "Parameter noch mal senden"

von Andreas H. (andario)


Bewertung
-1 lesenswert
nicht lesenswert
Hi,

dieses Ping-Pong-Spiel ist Teil eines Sicherheitskonzepts, ich hab mir 
das nicht ausgedacht.
Es geht nicht nur darum, zu prüfen, ob die Parameter richtig übertragen 
wurden (dann wäre dein Ansatz ausreichend), sondern es soll auch geprüft 
werden ob B die Parameter auch wirklich verwendet hat, und nicht 
vielleicht noch die vorherigen. Also nicht nur CRC über den RX Buffer.

Also zurück zur Frage: Ist es rein mathematisch möglich, dass 0xFFFF 
rauskommt?

von Johannes O. (jojo_2)


Bewertung
5 lesenswert
nicht lesenswert
Ja.

In hex:
000099C0 -> 0xFFFF
AFFE9A51 -> 0xFFFF
CAFE6E8E -> 0xFFFF

https://crccalc.com/

Euer Sicherheitskonzept müsste mal durch nen Review, so ergibt das wenig 
Sinn. Ich kann dir da innerhalb von wenigen Sekunden nahezu beliebige 
Outputs generieren.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
-1 lesenswert
nicht lesenswert
Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit. 
Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann 
muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist 
0xffff.

Nehmt also lieber ein zusätzliches Byte oder Bit, um "Fehler" zu 
signalisieren. und wenn es im 7ten Byte ist, weil dessen Wert nur bis 42 
geht.

von Cyblord -. (cyblord)


Bewertung
-4 lesenswert
nicht lesenswert
A. S. schrieb:
> Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit.
> Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann
> muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist
> 0xffff.

Dann kann man gleich alle Daten immer doppelt senden und sich CRC 
sparen.

von Johnny B. (johnnyb)


Bewertung
-2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> A. S. schrieb:
>> Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit.
>> Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann
>> muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist
>> 0xffff.
>
> Dann kann man gleich alle Daten immer doppelt senden und sich CRC
> sparen.

Sehe ich auch so.
Ein CRC bietet keine 100% Sicherheit, dass die Daten korrekt sind, nur 
eine hohe Wahrscheinlichkeit.

von Christian B. (luckyfu)


Bewertung
-1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Dann kann man gleich alle Daten immer doppelt senden und sich CRC
> sparen.

Wenn du sie sogar 3 mal sendest kannst du nachher demokratisch 
entscheiden, wer vermutlich korrekt ist. Das 3 Übertragungen gestört 
sind kann vorkommen, dass alle 3 an der selben Stelle gestört sind ist 
indes sehr unwahrscheinlich

von Erich J. (erich24)


Bewertung
-1 lesenswert
nicht lesenswert
Wenn Du es sicher willst bau zwei "gelbe Container" bestehend aus
1. - Nutzdaten
     Zähler oder Zeit des Absendens
     CRC über Container 1
2. - Nutzdaten invers
     Zähler oder Zeit des Absendens
     CRC über Container 2
Füge Container 1 + 2 zusammen und bilde über diese Daten eine weitere 
CRC.

Das ist schon ziemlich sicher.
Merke bei den CRCs können die gleichen CRCs für unterschiedliche Daten 
vorkommen (Hamming Distanz)

Gruß
Erich24

von Johannes O. (jojo_2)


Bewertung
0 lesenswert
nicht lesenswert
Christian B. schrieb:
> Wenn du sie sogar 3 mal sendest kannst du nachher demokratisch
> entscheiden, wer vermutlich korrekt ist. Das 3 Übertragungen gestört
> sind kann vorkommen, dass alle 3 an der selben Stelle gestört sind ist
> indes sehr unwahrscheinlich

Kommt aufs Fehlermodell an. Es kann schon Bitfolgen geben die anfälliger 
sind als andere. Kommt auf den Übertragungskanal an.


Bevor wir hier groß spekulieren:
@andario: Gib uns doch bitte ein paar Infos mehr zu deiner Anwendung. 
Dann lässt sich das was sinnvolles überlegen. Aktuell ist es nur 
Stochern im Nebel.
- Wieviel Daten?
- Welche Daten?
- Wie übertragen?
- Welche Bandbreite hast du zur Verfügung?
- Wie groß ist die geschätzte Fehlerwahrscheinlichkeit?
- Wie gefährlich ist das Auftreten eines Fehlers? (Tod, Sachschäden, 
genervter Benutzer, ?)

von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ein guten Protokol ansat ist zB :

A) Cmd + CRC  --> B) CRC ok, mach was
              <-- B) Antwort + Data + neuer CRC

                  B) CRC falsch, mach nichts
A) timeout.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Cyblord -. schrieb:
>> A. S. schrieb:
>>> Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit.
>>> Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann
>>> muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist
>>> 0xffff.
>>
>> Dann kann man gleich alle Daten immer doppelt senden und sich CRC
>> sparen.
>
> Sehe ich auch so.
> Ein CRC bietet keine 100% Sicherheit, dass die Daten korrekt sind, nur
> eine hohe Wahrscheinlichkeit.

Es geht doch nicht darum, eine CRC auf 2 Bytes zu setzen. Und die Daten 
doppelt ist dann noch weniger sicher wegen common cause.

Es ging darum, dass der TO wissen wollte, ob es eine bestimmte CRC gibt. 
Und ich habe dargelegt, dass jeder beliebige Datenstrom durch 2 weitere 
Bytes zu jeder gewünschten CRC führt. Selbst ohne vorherige Daten.

von Route_66 H. (route_66)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo!
Der Sender selbst kann doch verhindern, dass seine eigene CRC 0xFFFF 
ist.
Durch setzen eines ungenutzten Bits in einem Datenbyte kann er selbst 
sicherstellen, dass das Datentelegramm nie den Wert 0xFFFF als CRC 
ergibt.
Das war jetzt einfach.

von Andreas H. (andario)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo zusamen,

danke für die rege Beteiligung!
Wir haben uns jetzt auch überlegt, dass man ja einfach beim Erstellen 
der Parameter schon pfüfen kann, dass 0xFFFF nicht vorkommt, und falls 
doch einfach ein ungenutztes Bit (wir haben sogar in einem Kontrollbyte 
noch reservierte bits!) verwenden kann um das zu verhindern.

Grüße,
Andario

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> wir haben sogar in einem Kontrollbyte noch reservierte bits

Dann verstehe ich das ganze Gebastel nicht; dann kannst Du ja gleich so 
eines nehmen um besagten Fehler zu signalisieren und nicht die CRC dafür 
zu missbrauchen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.