50 Hex hat nachweislich eine Länge von 7,
unbekannte ungeklärte Dinge hier zu diskutieren macht keinen Sinn,
ansonsten habe ich es ja schon beantwortet,
falls du den Schritt String -> Zahl nicht kennst, da gibt es parse-Methoden,
vielleicht besser aus der Long-Klasse statt Integer
-------
noch eine anschauliche Umrechung: jeder Hex-Wert braucht 4 Bits,
ein Byte von 8 Bit läßt sich immer als 2 Hex darstellen (00 bis FF), das kennst du vielleicht,
"CEE88040" hat 7 volle Stellen, die alleine benötigen 7*4 = 28 Bits, das erste C auch noch 4, macht 32
im prinzip wissen wir doch was er sucht, nur uns fällt keine lösung ein ... im zweifelsfall sollte der TO mal seine ihm präsentierte Aufgabenstellung 1:1 widergeben.
das problem ist, dass ich ja wirklich nicht zu hundert Prozent sagen kann, was ich suche.
Ich weiß nur, dass ich ein String habe in hexadzimaler Form und dazu irgendeine Länge, welche ich ja für die obigen Beispiele mal angegeben habe (ich kann auch noch mehr angeben).
Und ich suche halt irgendeinen Weg, wie man auf diese Werte kommt.
Ich bin nicht mit Diggas Post einverstanden, ich bin mir nicht sicher was der TE wirklich machen muss und was er sucht. So wie ich das verstehe möchte er im Grunde wissen, wieviel Bit man zur Darstellung der Zahl in Binärdarstellung minimal benötigt. Für 0x50 = 0101 0000 in binär wären das 7 Bit. Für 0xCEE88040 =11001110111010001000000001000000 kommt man aber auf 32 Stellen und nicht auf 27. Entweder stimmt die Aufgabe nicht, oder der TE hat sich verlesen / vertippt. So macht das keinen Sinn zu raten.
Ergo wäre es sinnvoll mehr Beispiele zu haben. Im übrigen würde die Aufgabe dann auch nicht mit getBytes.length funktionieren. Da könnte er getBytes machen und müsste dann mittels ner Maske durch verunden die Vorderste eins im MSB suchen und daraus dann die Länge bestimmen.
Also meiner Meinung nach stimmt da was nicht, bzw. musst du uns erst erklären was "(last byte alligned on MSB)" hier bedeutet. Last byte von was, MSB=most significant byte???.
Was mir allerdings aufgefallen ist:
Hex: 53 58 7B C8
01010011010110000111101111001000 in Binär
01010011010110000111101111001 in deiner Angabe
Hm, ich glaube gemeint ist, das das letzte Byte, wenn man von rechts nach links ließt, das MSB ist. Aber irgendwie macht das für mich nicht so Sinn die Nullen hintendran wegzulassen... Aber nun gut wir wollen ja hier nicht über Sinn und Unsinn von schwachsinnigen Aufgaben reden.
Kurzer Tipp (schnell hingehackt...) was du als Grundlage verwenden kannst um dein Problem zu lösen:
Java:
publicstaticvoidmain(String[] args){byte a =(byte)0x10;byte mask =(byte)0x01;int counter =0;boolean found =false;while(counter <8&&!found){if((a & mask)!=(byte)0x00){System.out.println("Anzahl der Nullen: "+ counter);
found =true;}
mask <<=1;
counter ++;}}
Das Problem ist nur, dass das Most significant byte das erste byte und nicht das letzte ist. Im fall von
01010011010110000111101111001000
wäre 0101
oder zumindest 1010
das most significant byte, weil es ja den grösten unterschied in der Zahl, die am Ende rauskommt ausmacht. Ich habe noch nie von algorithmen gehört, die das Most significant byte verändern. Ich weis, dass bei Steganographie das Least Significant byte verändert wird, also das byte das am wenigsten unterschied macht.
Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
das kann nicht funktionieren, weil z.B. bei Länge 58 --> 42DA39AC5951FEC0
erst die 4 Nullen von 0000 wegfallen und dann noch zwei Nullen von dem C (1100), deshalb 64-6=58
Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
ist nur schwer möglich. Meine Aufgabe ist es die KECCAK Hashfunktion zu implementieren. Es ist auch alles soweit fertig. Bloß muss ich diesen Wert von der Länge eine hexadezimalen Strings berechnen können.
Wie es funktioniert soll, wissen wir ja mittlerweile. Wie nehmen die Anzahl an Stellen (also die Länge string.length()*4 und ziehen dann von hinten alle Nullen ab, bis die nächste 1 kommt. Dann haben wir die Länge. Bloß wie kann man das implementieren?
Das Problem ist nur, dass das Most significant byte das erste byte und nicht das letzte ist. Im fall von
01010011010110000111101111001000
wäre 0101
oder zumindest 1010
das most significant byte, weil es ja den grösten unterschied in der Zahl, die am Ende rauskommt ausmacht. Ich habe noch nie von algorithmen gehört, die das Most significant byte verändern. Ich weis, dass bei Steganographie das Least Significant byte verändert wird, also das byte das am wenigsten unterschied macht.
Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
Schonmal was von Big und Little Endian gehört? Beim Little Endian steht das MSB an der niedrigsten Adresse im Speicher, beim Big Endian an der höchsten Adresse.
da's definitiv was faul...
1. dezimal 50 ist hexadezimal 32 -> 6 Bits (0-5)
2. CEE88040 umgedreht ist (0) 4088EEC -> 27 Bits (0-26)
3. Big Endian: 40808ECE -> 31 Bits (0-31)
Daraus folgt, dass es sich nicht mal mit Little- bzw. Big Endian lösen lässt.
Die Beispielergebnisse sehen wirklich sehr nach "hingezaubert" aus. Denke nicht, dass da ein vernünftiger Algo hintersteckt.
importjava.math.BigInteger;publicclass HEX_TO_BIN_STRING
{publicstaticvoidmain(String[] args){// Test mit CEE88040;long test =0xCEE88040L;// long, sonst wird's negativBigInteger bi =BigInteger.valueOf(test);System.out.println(bi.toString(16).toUpperCase());String bin = bi.toString(2);while(bin.length()%2!=0){
bin ="0"+ bin;}System.out.println(bin);int index = bin.length()-1;while(bin.charAt(index)=='0'){
index--;}
bin = bin.substring(0, index +1);System.out.println(bin +" ("+ bin.length()+")");System.out.println();// Test mit 50;
test =0x50L;// long, sonst wird's negativ
bi =BigInteger.valueOf(test);System.out.println(bi.toString(16).toUpperCase());
bin = bi.toString(2);while(bin.length()%2!=0){
bin ="0"+ bin;}System.out.println(bin);
index = bin.length()-1;while(bin.charAt(index)=='0'){
index--;}
bin = bin.substring(0, index +1);System.out.println(bin +" ("+ bin.length()+")");}}
das funktioniert aber leider auch nicht, zumindest nicht bei allen.
Bsp. 0127A1D340 kommt statt 36 28 raus
ich habe gelesen es gibt eine klasse bitset in java, mit welcher man das vielleicht machen könnte, aber wie kriegt man den string überhaupt in die bitset rein (in bits)
Dann erklär' dem lieben Forum doch mal, wie du auf deine Ergebnisse kommst. Sind die etwa vorgegeben? Weil egal, was man nun noch wie dreht, deine Ergebnisse lassen sich iwie nicht berechnen. Auch mit BitSet nicht.
Also ich komme zumindest noch auf 30, wenn ich in meinem Code "% 4" statt "% 2" (Zeilen 12 und 29) schreibe.
Hab ich doch schon gesagt. Hier nochmal ein paar Werte:
Code:
Len = 1
Msg = 00
Len = 2
Msg = C0
Len = 3
Msg = C0
Len = 4
Msg = 80
Len = 5
Msg = 48
Len = 6
Msg = 50
Len = 7
Msg = 98
Len = 8
Msg = CC
Len = 9
Msg = 9800
Len = 10
Msg = 9D40
Len = 11
Msg = AA80
Len = 12
Msg = 9830
Len = 13
Msg = 5030
Len = 14
Msg = 4D24
Len = 15
Msg = CBDE
Len = 16
Msg = 41FB
Len = 17
Msg = 4FF400
Len = 18
Msg = FD0440
Len = 19
Msg = 424D00
Len = 20
Msg = 3FDEE0
Len = 21
Msg = 335768
Len = 22
Msg = 051E7C
Len = 23
Msg = 717F8C
Len = 24
Msg = 1F877C
Len = 25
Msg = EB35CF80
so das reicht hoffentlich, damit mir keiner mehr unterstellt, ich denk mir die Werte aus.
Wie die (per Handrechnung für mich) darauf kommen, hab ich ja erklärt. Hier das habe ich noch in einem der Ihrer Paper gefunden, was evtl. helfen könnte.
The bits of the
input message M are numbered from i = 0 to i = |M| - 1. When the bits are gathered in
bytes, it implies the equivalent numbering i = ibit + 8ibyte with 0 <= ibit < 8.
In our internal convention, ibit = 0 indicates the least signicant bit (LSB) of a byte while
ibit = 7 indicates the most signicant one (MSB). The NIST convention [2] is dierent: The
bits of a byte are numbered from 0 for the MSB to 7 for the LSB. To be compatible with the
API convention outside and with our convention inside, the following formal bit-reordering
is performed on the input bit string M before it is processed:
For all bytes that contain 8 bits, position ibit+8ibyte is mapped to position 7-ibit+8ibyte.
For the last byte if it contains p < 8 bits, position ibit + 8ibyte is mapped to position
(p - 1) - ibit + 8ibyte.
This mapping is bijective and does not aect the security.
In practice, the above operation cancels with the change of convention, so there is nothing
to do, except:
For the last byte if it contains p < 8 bits, the bits are shifted by 8-p positions towards
the LSB (i.e., to the "right").
5.2
Ich glaube auch anhand dieser Werte nicht mehr, dass es stimmt, dass man immer nur die Nullen wegnehmen muss, weil das stimmt bei Länge 6 oder 9 ja z.B. auch nicht.
also selbst mit der beschreibung da .. ich kann probieren was ich will für manche klappt mein verständnis des algos für manche wieder nicht, änder ich bissel was ab, weil ich glaube es falsch verstanden zu haben, klappts wieder für andere, aber für vorherige nicht mehr .. irgendwie is da echt der wurm drin ^^
mal als bsp:
98 = länge 7 ... 1001 1000 .. so fangen wir an .. da kann ich kreativ sein wie ich will und drehen und machen und shiften, damit es annähernd dem algorithmus ähnelt .. ohne willkür komm ich da nicht auf ne anreihung, die 7 bits füllt. und wenn ich davon ausgehe das mit length vielleicht sogar die position des letzten relevanten bits genannt sei .. dann frag ich mich wie die bei 00 = 0000 0000 auf 1 kommen wollen?!
wie gesagt, man kann es für manche passend hinbekommen aber nicht für alle, so wie ich das hier versucht hab.
Ich glaube auch anhand dieser Werte nicht mehr, dass es stimmt, dass man immer nur die Nullen wegnehmen muss, weil das stimmt bei Länge 6 oder 9 ja z.B. auch nicht.
Ist das ein veröffentlichtes Paper? Falls ja, geb mal ne Quelle an. So langsam möchte ich mir das Paper mal ansehen. Das kann doch nicht sein das da so ein Murks bei rumkommt.
Zumindest bei C0 = 2 & C0 = 3 ist den sicherlich ein Fehler unterlaufen.
ja bei C0 = 2 oder 3 denk ich is eher n fehler beim aufgabensteller .. das kann so definitiv nicht hinhauen, aber an dem paar sollte man sich nich aufhängen .. gibt ja genug andere wertepaare die es zu knacken gilt
Ist das ein veröffentlichtes Paper? Falls ja, geb mal ne Quelle an. So langsam möchte ich mir das Paper mal ansehen. Das kann doch nicht sein das da so ein Murks bei rumkommt.
Ich denke auch, dass genau bei dem einen Beispiel von 2 und 3 ein Fehler vorliegt...
Das ist eine offizielle Datei: The Keccak sponge function family und dort runterladen : Known-answer and Monte Carlo test results version 3.0
und nach dem runterladen auf ShortMsgKAT_egal gehen und da stehen die Werte!
auf der seite sind auch die ganzen anderen paper...
den ausschnitt aus dem einen, wo etwas dazu stand hab ich ja schon gepostet...
Ich weiß ja dass es eigentlich das macht, aber in der Übersicht (die ihr euch ja auch alle mal angucken könnt) sind noch mehr solche Wertepaare wo es nicht hinhaut!!!
Bsp. 17 --> 4FF400
ist ja eigentlich 010011111111010000000000
damit müsste Länge 14 rauskommen
oder 19 --> 424D00
010000100100110100000000
müsste ja eigentlich 16 rauskommen.
Die haben sich ja nicht bei jedem Beispiel verschrieben!!!
Also muss da irgendein anderer "Trick" dahinter stecken, aber ich weiß ihn leider auch nicht.
Unglaublich eh!
Anstatt hier die Zeit von so vielen Leuten (+ die, die bisher hier nur gelesenhaben wie ich) zu vergeuden die hier 2 Seiten lang versucht haben aus deinen unvollständigen, falschen und zusammengeratenen Informationen eine sinnvolle Fragestellung und Lösung zu erkennen, hättest du vielleicht erstmal selber ein bisschen recherchieren können was das überhaupt für Daten sind die du hier angibst. Die Datei ShortMsgKAT.txt ist eine Test-Definitionsdatei. Die Daten die dort drin stehen unter "Len" und "Msg" sind die Parameter mit dem der Algorithmus gefüttert wird und nicht irgendwelche Ergebnisse.
Mit "Hexadezimal in Binär umwandeln", oder "Nullen am Ende abschneiden" oder "Bits zählen bis zur letzten 1" hat das ganze auch überhaupt nichts zu tun, der Algorithmus ist schon ein bisschen komplexer...
ach ja mister superschlau, dann erklär mir doch mal was die werte für einen sinn ergeben sollen, wenn sie sich denn nicht berechnen lassen.
Natürlich sind das eingabewerte für die Methode, aber die müssen ja auch irgendwie ableitbar und berechenbar sein.
Aber du ja so intelligent bist, kannst du mir und dem forum ja bestimmt auch sagen, was die werte für einen sinn ergeben und wie man sie ermittelt oder einsetzt!!!
ach ja mister superschlau, dann erklär mir doch mal was die werte für einen sinn ergeben sollen, wenn sie sich denn nicht berechnen lassen.
Natürlich sind das eingabewerte für die Methode, aber die müssen ja auch irgendwie ableitbar und berechenbar sein.
Aber du ja so intelligent bist, kannst du mir und dem forum ja bestimmt auch sagen, was die werte für einen sinn ergeben und wie man sie ermittelt oder einsetzt!!!
Also jetzt werd mal nicht so unfreundlich. Ich meinem Anonymen Vorposter Recht geben. Du hast eine wirre Aufgabenstellung gepostet und mit der Hilfe sehr vieler wurde so langsam ein Schug draus. Du vorderst hier sehr viel, dafür dass du sehr wenig selbst lieferst.
Deswegen habe ich auch seit dem Anfang nicht mehr gepostet. Das fing schon an mit dem Wirren Thema Titel: Länge eines Strings berechnen. Jetzt sieht man ja, dass das rein gar nichts mit deiner Aufgabe zu tun hatte ...
wenn er sich mal alles richtig angeguckt hätte, dann hätte er auch gesehen, dass in den teilweisen Implementierungen auf der Seite bei den Eingabewerten immer steht, dass der String und SEINE Länge übergeben wird (in bits) und damit hat es was miteinander zu tun.
Ich weiß dass ich teilweise sehr verwirrend beschrieben hab was ich gerne hätte, aber das lag daran, dass ich es selber ja nicht genau weiß.
Ich habe auch nur die Werte und weiß, dass ich sie brauche. Und das ich selber nicht viel poste liegt daran, dass ich den ganzen Tag für meine Masterarbeit schreibe und leider dann auch keine Idee habe wie man das lösen kann.
Ich hoffe trotzdem, dass sich vielleicht noch der ein oder andere findet, der mir versucht zu helfen und vielleicht finden wir ja auch irgendeinen Weg wie man darauf nun kommt....
Ich weiß nicht wie du auf die Idee kommst dass es einen Zusammenhang zwischen der Länge und der Nachricht geben muss (außer dass Len <= bitAnzahl(Msg) sein muss). Nochmal: Das sind Test Eingabedaten um die Korrektheit eines Algorithmus zu überprüfen, da gibt es nichts zu berechnen oder ermitteln oder einen tieferen Sinn dahinter. Die Testdaten wurden offenbar von der NIST ausgewählt und vorgegeben.
Ich weiß nicht wie du auf die Idee kommst dass es einen Zusammenhang zwischen der Länge und der Nachricht geben muss (außer dass Len <= bitAnzahl(Msg) sein muss). Nochmal: Das sind Test Eingabedaten um die Korrektheit eines Algorithmus zu überprüfen, da gibt es nichts zu berechnen oder ermitteln oder einen tieferen Sinn dahinter. Die Testdaten wurden offenbar von der NIST ausgewählt und vorgegeben.
"""Pad M with reverse-padding to reach a length multiple of n
M: message pair (length in bits, string of hex characters ('9AFC...')
n: length in bits (must be a multiple of 8)
Example: pad([60, 'BA594E0FB9EBBD30'],8) returns 'BA594E0FB9EBBD13'
"""
Gesucht wird der erste Teil des Nachrichtenpaares, ergo die "Länge in Bit".
So wie ich das sehe ist das die Länge des Eingabewortes ohne das Padding durch Bytealignment.
D.h.:
Code:
(Position der letzten 1 in Binär) <= m <= (Länge des Strings*4)