Candrasengkala being a symbol of the number of years, sometimes designated as the characters of the year itself. Western culture called the symbolizaiton figure this year as Chronogram.
Candrasengkala is the moon statement.
You may have made a mistake on the numbers…
Pythagoreans used numbers to represent various planets and elements and said 5 stood for fire; 6, earth; 8, air and 12, water. Cornelius Agrippa wrote that the energy found in the number 5 could exorcise demons and serve as an antidote to poisons. I’d be careful with how you use some of those numbers. They may be dangerous!
I think you’ll find that you made a mistake saying there are 21 grams in an ounce. The mistake results in a fascinating conclusion though.
There are 28.3495 grams to an ounce and not 21 leaving a difference of 7.3495.
Look at that number. 7.3…7*3=21. Look at the numbers after the decimal ----------3+4+9+5=21 !!!
yup, mistake on the grams…i still think its a chronogram we must get the numbers from. The name i used was for the type of chronogram used in poetics Where we come up with the numbers and reverse them. examples I posted on the number interpretation are correct, they were taken from the source. They are subjective though, there is no absolute definition for this and that…
We have to determine the numbers ourselves, like the nimrod quote. I 100% believe thats what we are to do…also there was a fun theory that a soul weighs 21 grams. One could tie that to the gate as well…
I was able to compile the Crypt::Lucifer perl module in Windows in an MSYS2 shell. But I noticed that the module only decrypts a single 16 byte block, so we need to call the decrypt method for each 16 byte block of the code.
Here’s a revised script:
[code=perl,‘lucifer.pl’]#!/usr/bin/perl
use bytes;
use Crypt::Lucifer;
sub decrypt{
my $ct = $[0];
my $key = $[1];
# We only decrypt n*16 bytes (we discard the remaining bytes)
my $size = length($ct) - length($ct) % 16;
my $pt = “”;
my ($offset, $lucifer);
$lucifer = new Crypt::Lucifer( $key );
print decrypt($HALOS_code, $ARGV[0]) . “\n”;[/code]
The key that’s passed to the cipher is the ASCII representation of the password typed on the command-line. If it’s shorter than 16 characters, it’s padded with null characters.
I’m going to write another version of the script that reads passwords from a file, so I can try passwords from a compiled list of passwords. I also need to check that this implementation works as expected by comparing encryption/decryption results with another implementation. But that’s work for another day.
EDIT: Something is messed up with the Crypt::Lucifer perl module, at least with my build of it. It doesn’t produce the same ciphertext as the Outerbridge C implementation. Also, looking at the source code, it should be able to encrypt/decrypt messages of any length, but somehow the method only returns 16 bytes. I’m going to have to test it on a proper Linux system.
It does seem that the cipher itself operates on 16 byte blocks, not really sure why its returning like that though, it doesn’t when you don’t use pack() so assuming its something to do with the returned array, although my perl is awful so I’m really only guessing!
Very difficult to find some example encrypted data as by default it is pure binary so unless hex or base64 encoded just shows up as rubbish on screen so its hard to validate that these scripts are working.
The implementation in lucifer-outerbridge-5.0.tar.gz came with some test vectors, which I’m testing against:
[code]Key: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Input: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Cipher: a2 01 fc 18 d6 2c 85 ef 59 65 a5 82 95 bb f6 09
Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Cipher: 9d 14 fe 43 77 aa 87 dd 07 cc 8a 14 52 2c 21 ed
Key: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Input: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Cipher: 97 f1 c1 04 b0 f1 20 d1 94 c0 70 24 f1 48 15 ed
Key: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Input: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Cipher: d4 42 a3 4d d7 0e 2b 41 56 eb 0f 2a 8a de d1 a7
Key: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Input: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Cipher: cf 46 62 2f a9 85 46 bb 9a 5b c0 02 39 eb 0c 92
Key: fe dc ba 98 76 54 32 10 01 23 45 67 89 ab cd ef
Input: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Cipher: 7f af 65 bf c5 45 8f d2 dc 9c c2 26 60 12 ef 44[/code]“Input” = plaintext, “Cipher” = ciphertext
The logo has been changed to Belgium’s colors as a response (I assume) to the recent terror attacks at the Zaventem Airport as well as the Maelbeek Metro Station in Brussels.
Theory: guys, the hexcode. It’s called a palindrome. Taken from the password benalhopaillier, you Get parallel, benalohpaillier as a pw i think was supposed to remind him what the actual pw was, or structure. not BP oil brony,
Storms hint "authorised for release 12.12.12. That is the last time we a get triple match date, the next time we get one is in 85 years. On Jan 1st 2101. Or written out 1012101. 21 into. 1. Both directions 1012101 is a palindrome. The octodog hint, 080, is a palindrome. Look at the hexcode, we need to arrange it in a palindrome order, the very first few characters, b32b003= b30203b it’s a palindrome. Look at the next set of characters, they need to be arranged as a palindrome, same thing!!!
did you read the whole post? I know what a palindrome is, my example was 1012101, then my next example was b30203b. Not the hex as it sits, it needs to be ordered in a way that can be read the same backwards and forwards. Looking at dna sequences in a double helix you can find many palindrome they may be running in the opposite direction but are still considered a palindrome. @JeffMOD
when I said I took parallel from the benalohpaillier, that is what got me looking at parallel numbers and strings, and dates, that is how I came to the 12.12.12. post by storm, which lead me to 21 into 1 date and 1012101 and palindromes. currently doing a frequency count of all letters and numbers and hopefully will find a proper working order. if not, then I don’t.
perhaps not, but the 121212 to 1012101, got me thinking at some of the hints, why make sure to put “authorized for release 12.12.12” I think its there as a hint. , the pizza is a lie being reversed underneath it, the numbers displayed backwards with them going the opposite direction underneath them. just a theory, perhaps nothing will come of it. I thought it was worth mentioning. as for the amount of permutations, it will make it a lot of easier if there is a break point per line. every word is different lengths, maybe each palindrome will be different lengths as well. also, I mentioned earlier but took it down to reword my post. 99% of my stuff comes across as jumbled and scatterbrained so I’m trying to refine it a bit. I had mentioned that the borealis from portal 2, and Judith mossmans find and message.
Dr. Judith Mossman is a scientist who plays an integral role in the Half-Life 2 series. She is a cunning and manipulative triple agent, aiding both sides during the Uprising but eventually siding with the Resistance. Later on she discovered a secret and powerful project that could be used against the Combine, in a vanished ship named the Borealis.
she looks to be in the arctic, the borealis which is an icebreaker is where she is headed. the interesting part of this. Borealis, or boreas, is the god of north wind, who is related and tied to helios or HALOS. we know that time travel IS DEFINATLEY part of the half life story. I did not realize how important the borealis was to the halflife timeline though. possibly related?
EDIT: could someone please change their pc date to jan 1st 2101 and run through the known sites? I’m unable to get my year to that date.
Yah… this perl implementation is fubar. I Installed it on Ubuntu and tried encrypting and then immediately decrypting a bunch of different strings. I very regularly got truncated or mangled results back (this was accounting for the result being null padded).
Edit: The copyright for the lib is 2014, and the current version is 0.1. So this implementation probably didn’t even exist when 752 appeared.
I’m working on getting the Javascript Lucifer program up and running - the C code has been converted to Javascript, and I am in the middle of making a simple HTML file to interact with the Lucifer function. Give me a while longer.
just ran the first line through with what I’m working on. and this popped out. @P]cKoJG:k@sBSk@PT`KxlamK@UV&M@UWS2)AZM2)>[KAtRSV2)dIc@lH>c2E#)VxlajI@kffP@lZPZAi)
how about that last word.? PIZZA,this looks pretty damn promising
While I agree with you that it’s a delicious looking lead, there’s no way this has any value. Sorry. (Still, someone else should be looking at it and saying that. I’ve always struggled to keep up with this thread.)
The fact that a five letter segment of a jumbled string of characters that can be used to make a word relevant to the ARG could be considered a sign of a possible lead in the first place is testament to how desperate we are for clues. This single puzzle has stumped us for so dang long.
Yeah, looks like it. However, the C code in it is based (almost verbatim) on the C implementation by J. M. Smith, which is from 1991. So if the perl module had been working properly, it might still have been relevant.
Which C implementation did you use as reference?
I’ve tried both C implementations, but they produce different results. In fact, it looks like every damn implementation produces a different result (not very promising, I know). I think the problem is that they all read/process the bytes and/or bits in different order.
So I went to the source. I typed out Arthur Sorkin’s original Fortran code from his 1983 paper (https://www.fuseki.com/lucifer.pdf). I got it to compile using gfortran, but it would just segfault when I tried to run it. Later on, I took another look at it and found a bug in the original Fortran code which caused data to be offset and overflow an array, which caused a buffer overflow.
After fixing the bug and doing some slight modifications to the main program (removed a timed do loop used for testing the performance of the lucifer subroutine, and added some write statements to print out the ciphertext), I was able to run some test vectors:
Key: 0123456789ABCDEFFEDCBA9876543210
Plain: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
Cipher: 7C790EFDE03679E4BF28FE2D199E41A0[/code]As you can see, they don’t match the test vectors I posted earlier, which match the output from Outerbridge’s C implementation. But we can use these test vectors to verify “our” implementation against Sorkin’s original Fortran implementation.
Smith’s C implementation is the one implementation that most closely resembles Sorkin’s Fortran program. But there’s a bug in it: While the bytes are read in the same order as the Fortran program, the bits are read backwards. As a result, the ciphertext it produces is different. It’s easily fixable (but do we want to fix it?).
Outerbridge’s C implementation, however, doesn’t look anything like the Fortran program. They’ve done a lot of optimizations that make it much more difficult to sort out exactly why it doesn’t produce the same output as Sorkin’s original Fortran program.
I’m not sure what this means for the Lucifer cipher theory, because the question now is: If it really is the Lucifer cipher and Storm used any one of these implementations, which one did he use?
Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.
