Because crypto is so easy, anybody can write their own



  • Came across this when I was looking at the Wikipedia article on the Caesar cipher:

    In 2011, Rajib Karim was convicted in the United Kingdom of "terrorism offences" after using the Caesar cipher to communicate with Bangladeshi Islamic activists discussing plots to blow up British Airways planes or disrupt their IT networks. Although the parties had access to far better encryption techniques (Karim himself used PGP for data storage on computer disks), they chose to use their own scheme instead (implemented in Microsoft Excel) "because 'kaffirs', or non-believers, know about it [ie, PGP] so it must be less secure".
    The Wikipedia article lists [url=http://www.theregister.co.uk/2011/03/22/ba_jihadist_trial_sentencing/]this Reg article[/url] as the source, which has more detail:
    Woolwich Crown Court was told that Bangladeshi Islamic activists who were in touch with Karim had rejected the use of common modern systems such as PGP or TrueCrypt in favour of a system which used Excel transposition tables, which they had invented themselves....


    Karim, an IT specialist, had used PGP, but for storage only.


    Despite urging by the Yemen-based al Qaida leader Anwar Al Anlaki, Karim also rejected the use of a sophisticated code program called "Mujhaddin Secrets", which implements all the AES candidate cyphers, "because 'kaffirs', or non-believers, know about it so it must be less secure".


    I guess it didn't occur to him that non-believers might also have come up with the idea of a substitution cipher at some point. (It's not clear to me from the Reg article whether it was actually a Caesar cipher or whether it was a more general subsitution cipher.) Implementing it in Excel is just a bonus. :)

    Of course, The Reg being what it is, the impression I get from every other article I read on the subject was that the police were in fact decrypting his stored emails which were underneath multiple layers of encryption (presumably including PGP since it notes he used that for storage). It's not as if he was relying on just the substitution cipher, though the Reg tries to make it sound that way.

    But still. The first rule of using cryptography is never, ever roll your own.



  • Omitting "double ROT-13 to be more secure" joke...



  •  nBu tstil l.Th efirs trul eo fusin gcryptograph yi sneve r,eve rrol lyou row.



  •  Let's play Guess the Retarded Crypto Algorithm!

    hT eifsr turelo frcpyotrgpayhi senev,re ev rorlly uo rwo!n


  • Discourse touched me in a no-no place

    @dhromed said:

    Let's play Guess the Retarded Crypto Algorithm!
    . -... --. --. .-. --.- --.. -... . ..-. .-. .--. -... --.- .-. ..--..



    ;)



  • Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

  • Discourse touched me in a no-no place

    @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    [] is not a sequence point.

    Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.



  • @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    That all you got? I can do en- and decryption with a symmetric key in 3 lines!

    def crypt string, key
      string.split(//).inject('') { |s, c| s << (c[0] ^ key).chr }
    end


  • @FrostCat said:

    Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.

    Duh, obviously by typing []]]! CS gotta have the weirdest bbCode implementation I've ever seen.


  • Discourse touched me in a no-no place

    @FrostCat said:

    @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    [ is not a sequence point. Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.

    What have sequence points got to do with it? Nothing's being modified twice between any of them



    And &#91; and &#93; will give you [ ]



  • @db2 said:

    while (str[c]) str[c++]++;

    Actually, Acrobat Reader once did exactly that when I printed a document. I don't know if I still have the printout. If I find it, I'll post a photo.



  • @Scarlet Manuka said:

    Of course, The Reg being what it is, the impression I get from every other article I read on the subject was that the police were in fact decrypting his stored emails which were underneath multiple layers of encryption (presumably including PGP since it notes he used that for storage). It's not as if he was relying on just the substitution cipher, though the Reg tries to make it sound that way.

    According to WSJ,

    [quote user="http://online.wsj.com/article/SB10001424052748704570104576124231820312632.html"] 

    Among the steps Rajib Karim allegedly used to encrypt messages:

                <p>•
    

    Messages were stored on an external hard drive in files that appeared
    to have been created in one kind of program, but in fact used a
    different type of program

                <p>• The program used enables each file to run as a separate, password-protected 'virtual hard drive' </p>
    
                <p>• Text contained in those files also was in scrambled form unless decrypted with the help of a custom-built software program</p>
    
                <p>• Messages allegedly contained false names and other coded words</p>
    
                <p>•
    

    Didn't exchange messages as emails, which can be intercepted; instead
    uploaded them to publicly available websites that host files

                <p>• Used software to erase some electronic fingerprints from laptop</p><p>[/quote]I wouldn't call changing the file extension an encryption method myself, I'd call it a trivial obfuscation attempt, or for short I'd just call it FAIL.</p><p>@Scarlet Manuka said:<blockquote>But still. The first rule of using cryptography is never, ever roll your own.</p><p></blockquote> (Well, you have to be effing stupid to swallow all that religious jihadi shit in the first place.)&nbsp; And I'd say that the second rule of cryptography is don't use an easily dictionary-attacked passphrase on your PGPdisks.</p><p>(Yes, I'm assuming the SIS does not have some secret integer factoring technique.)  </p>


  • @fatbull said:

    @db2 said:

    while (str[c]) str[c++]++;

    Actually, Acrobat Reader once did exactly that when I printed a document. I don't know if I still have the printout. If I find it, I'll post a photo.

    If you do so, please make it a photo of the paper lying on a wooden table.



  • @derula said:

    [quote user="db2"]

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    That all you got? I can do en- and decryption with a symmetric key in 3 lines!

    def crypt string, key
      string.split(//).inject('') { |s, c| s << (c[0] ^ key).chr }
    end
    [/quote]

    Obviously there's only one true encryption method.

    char *str, *strout;
    int len, i;
    len = strlen(str);
    *strout = (char *)malloc(len);
    for (i = 0; i < len; i++){ strout[len - (i + 1)] = str[i];}
    

    (Please forgive the fact that my C's a little rusty and that I somehow think it's easier to write it from scratch instead of just googling it.)



  • @MiffTheFox said:

    @derula said:
    @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    That all you got? I can do en- and decryption with a symmetric key in 3 lines!

    def crypt string, key
      string.split(//).inject('') { |s, c| s << (c[0] ^ key).chr }
    end

    Obviously there's only one true encryption method.

    char *str, *strout;
    int len, i;
    len = strlen(str);
    *strout = (char *)malloc(len);
    for (i = 0; i < len; i++){ strout[len - (i + 1)] = str[i];}
    

    (Please forgive the fact that my C's a little rusty and that I somehow think it's easier to write it from scratch instead of just googling it.)

    I can do that in less code, too!

    string.reverse

    See? Also, why don't you just work from 0 to len/2 and exchange the outer characters? Just a character, no second string of same size needed.


    (Would have written that in C code but I don't really know C and probably would have written shit)



  • @dhromed said:

     Let's play Guess the Retarded Crypto Algorithm!

    |
    |
    v
    


  • @derula said:

    why don't you just work from 0 to len/2 and exchange the outer characters? Just a character, no second string of same size needed.
     

    Because it fails on strings of length zero?  (Boundary conditions, dude!)

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.



  • CQ DE IAGO
    MSG NR 0001/091411/1920E/FU
    GKNVT LNUWQ UBWKA HPKEG RRRVS
    BSMWG AFAKP IIENP HQCOZ ELZQY
    OSTAH UIQGO NMJWI JPFPP GQRWE
    JNWFS VJZOP BRUSU WUSQF YJEOF
    LCRUG PFFTM JSVJG VRTZC OMKNP
    IFWFV RFKLB NSTGM ///// GR028
    QSL QSL QSL



  • @da Doctah said:

    Because it fails on strings of length zero?  (Boundary conditions, dude!)

    Pseudocode:

    try {
      for (i = 0; i < len/2; i++) swap_characters(string, i, len - i + 1);
    } except {}

    Fixed! :D

    @da Doctah said:

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.

    I'm not technical enough to tell if that would end up being faster. Would it?


  • Discourse touched me in a no-no place

    @derula said:

    @FrostCat said:
    Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.

    Duh, obviously by typing []]! CS gotta have the weirdest bbCode implementation I've ever seen.

    I tried that and it didn't work and I decided (here comes TRWTF) not to waste my time figuring out how to do it.


  • Discourse touched me in a no-no place

    @PJH said:

    @FrostCat said:
    @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    [ is not a sequence point. Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.

    What have sequence points got to do with it? Nothing's being modified twice between any of them



    And &#91; and &#93; will give you [ ]

    What gets incremented first, str[...] or c? Are you sure your answer stays the same if you switch compilers? (Actually it doesn't really matter; I assumed db2's sample was deliberately stupid, because, well....)


  • Discourse touched me in a no-no place

    @FrostCat said:

    @PJH said:
    @FrostCat said:
    @db2 said:

    Pfft, I can do cryptography in three lines.

    char *str;
    int c;
    while (str[c]) str[c++]++;

    [ is not a sequence point. Edited: pretend that's a pair of brackets; I'm too lazy to figure out how to get the right one to display.

    What have sequence points got to do with it? Nothing's being modified twice between any of them



    And &#91; and &#93; will give you [ ]

    What gets incremented first, str[...] or c?

    The c++ is calculated first because of the precedence of [] , but since it's postfix, it doesn't matter - the old value of c is used.

    Are you sure your answer stays the same if you switch compilers?
    Yes, it's part of the C standard.


  • @FrostCat said:

    I assumed db2's sample was deliberately stupid

    Bingo.



  • @FrostCat said:

    What gets incremented first, str[...] or c? Are you sure your answer stays the same if you switch compilers?

    The C Operator Precedence says that the contents of [] are before the post-increment operators. So this means that the compiler will look at the contents of the brackets and then it will execute the post-increment inside the brackets before it would execute the post-increment outside of the brackets. This should be uniformly honored by all compilers. If not, that's a HUGE WTF.



  • Hai guyz can you check the syntax on my goofy joke plz? Thx!


  • ♿ (Parody)

    @blakeyrat said:

    Hai guyz can you check the syntax on my goofy joke plz? Thx!

    Plz send me the codes.



  • @derula said:

    @da Doctah said:
    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.
    I'm not technical enough to tell if that would end up being faster. Would it?
    I don't think so.  3 XORs vs 3 assignmnets, both should be a single op.


  • @Sutherlands said:

    @derula said:

    @da Doctah said:

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.
    I'm not technical enough to tell if that would end up being faster. Would it?
    I don't think so.  3 XORs vs 3 assignmnets, both should be a single op.
     

    The point never was that it was faster.  The point was that it used less memory.

     



  • @da Doctah said:

    @Sutherlands said:

    @derula said:

    @da Doctah said:

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.
    I'm not technical enough to tell if that would end up being faster. Would it?
    I don't think so.  3 XORs vs 3 assignmnets, both should be a single op.
     

    The point never was that it was faster.  The point was that it used less memory.


    Your mom uses less memory!



  • @dohpaz42 said:

    @FrostCat said:
    What gets incremented first, str[...] or c? Are you sure your answer stays the same if you switch compilers?

    The C Operator Precedence says that the contents of []] are before the post-increment operators. So this means that the compiler will look at the contents of the brackets and then it will execute the post-increment inside the brackets before it would execute the post-increment outside of the brackets. This should be uniformly honored by all compilers. If not, that's a HUGE WTF.

    Of course you have to evaluate operands before you use their value, but the actual order of evaluation and when side effects happen is generally unspecified. "Be done before the next sequence point" - that's about it.

    A compiler could copy c into a temp register, update c, read str and then update str. But it could also read c, read str, update str, update c and it would still be correct. Or read c, read str, update c, update str. Any alternative is fine because the result (i.e., the state at the next sequence point) is the same.

    As a rule of thumb, the result of an expression is well defined if, for every allowable ordering, each value is written at most once and never read thereafter.

    Note that this only applies to C and C++. Java and C# have different rules.



  • Is there ANY topic you guys can't turn into a boring-as-shit technical discussion?



  • @da Doctah said:

    @Sutherlands said:

    @derula said:

    @da Doctah said:

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.
    I'm not technical enough to tell if that would end up being faster. Would it?
    I don't think so.  3 XORs vs 3 assignmnets, both should be a single op.
     

    The point never was that it was faster.  The point was that it used less memory.

    What, like 1 register?



  • @blakeyrat said:

    Is there ANY topic you guys can't turn into a boring-as-shit technical discussion?
    Is there any topic you CAN'T complain about, when you could just ignore it?



  • @Sutherlands said:

    @blakeyrat said:

    Is there ANY topic you guys can't turn into a boring-as-shit technical discussion?
    Is there any topic you CAN'T complain about, when you could just ignore it?

    I like complaining better.



  • @blakeyrat said:

    Is there ANY topic you guys can't turn into a boring-as-shit technical discussion?

    Yes.


  • Discourse touched me in a no-no place

    char *str;
    int c;
    while (str[c]) str[c++]++;

    @fatbull said:

    A compiler could copy c into a temp register, update c, read str and then update str. But it could also read c, read str, update str, update c and it would still be correct. Or read c, read str, update c, update str. Any alternative is fine because the result (i.e., the state at the next sequence point) is the same.
    If your C compiler is doing anything other than evaluating the inner c++ first, evaluating str[c] next then incrementing the contents of that address then I'd advise you to ditch it for a Standard's compliant one.
    @fatbull said:
    As a rule of thumb, the result of an expression is well defined if, for every allowable ordering, each value is written at most once and never read thereafter
    You're spouting bollocks. http://c-faq.com/expr/seqpoints.html:

    Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.
    The code, as presented, is well defined, and has only one interpretation.


  • @PJH said:

    If your C compiler is doing anything other than evaluating the inner c++ first, evaluating str[c] next then incrementing the contents of that address  then I'd advise you to ditch it for a Standard's compliant one.

    Why do that? The important thing isn't that the compiler does things in a specific order (indeed, I'd be happy enough if it carried out both calculations at the same time), but that it looks like it does.

    In any case, this code fragment evaluates at least one indeterminate value before it reaches the str??(c++??), so a standard compliant compiler is allowed to do anything the hardware will support.


  • Discourse touched me in a no-no place

    @__moz said:

    but that it looks like it does.
    Well, yes - The Standard explicitly points this out; it describes the end behaviour - how the compiler actually gets there is (largely) irrelevant. Since we were talking about Standard behaviour, I didn't think to point it out at the time.@__moz said:
    str??(c++??)
    Well I suppose that's one way round the idiosyncrasies of CS/BBcode... :D



  • @PJH said:

    If your C compiler is doing anything other than evaluating the inner c++ first, evaluating str[c] next then incrementing the contents of that address then I'd advise you to ditch it for a Standard's compliant one.

    The side effects (writing back the incremented values) must happen after, but not necessarily immediately after the respective values have been read; and not even in any specific order. Cf. http://c-faq.com/expr/evalorder2.html, http://c-faq.com/~scs/cclass/krnotes/sx5l.html.

    @PJH said:

    http://c-faq.com/expr/seqpoints.html

    Further down:

    if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification.

    Which is what the last part of my rule of thumb was supposed to mean.

    @PJH said:

    The code, as presented, is well defined, and has only one interpretation.

    My point was that the result is well defined (the initial, not incremented values are used both times), but it is unspecified whether str[...] or c is actually incremented first.

     


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Is there ANY topic you guys can't turn into a boring-as-shit technical discussion?

    You must be new here.


  • Discourse touched me in a no-no place

    @PJH said:

    @__moz said:
    but that it looks like it does.
    Well, yes - The Standard explicitly points this out; it describes the end behaviour - how the compiler actually gets there is (largely) irrelevant. Since we were talking about Standard behaviour, I didn't think to point it out at the time.@__moz said:
    str??(c++??)
    Well I suppose that's one way round the idiosyncrasies of CS/BBcode... :D

    Holy fish paste, someone found a legitimate (for some value of the word) use for trigraphs!



  • @DaveK said:

    And I'd say that the second rule of cryptography is don't use an easily dictionary-attacked passphrase on your PGPdisks.
    Apparently it took the police 9 months to crack it, so I guess it falls somewhere in the range between "easily guessable" and "actually effective".


    Of course I'm relying on only vaguely trustworthy media accounts for the 9 month figure, so who knows? Maybe it only took them half an hour to crack it and they spent 9 months trawling through the results.



  • @FrostCat said:

    @PJH said:
    @__moz said:
    but that it looks like it does.
    Well, yes - The Standard explicitly points this out; it describes the end behaviour - how the compiler actually gets there is (largely) irrelevant. Since we were talking about Standard behaviour, I didn't think to point it out at the time.@__moz said:
    str??(c++??)
    Well I suppose that's one way round the idiosyncrasies of CS/BBcode... :D

    Holy fish paste, someone found a legitimate (for some value of the word) use for trigraphs!

     

    Except it reads naturally as "WTF is str?? (for that matter, WTF is c++??)"



  • @Sutherlands said:

    @da Doctah said:

    @Sutherlands said:

    @derula said:

    @da Doctah said:

    You don't even need the extra character.  Just do a triple-bitwise-XOR on the two character positions and they magically switch places.
    I'm not technical enough to tell if that would end up being faster. Would it?
    I don't think so.  3 XORs vs 3 assignmnets, both should be a single op.
     

    The point never was that it was faster.  The point was that it used less memory.

    What, like 1 register?

    Registers don't grow on trees, ya know!

     



  • @da Doctah said:

    Registers don't grow on trees, ya know!
     

    Exactly.

    That would make them scarce, because you'd need to pay for growing, picking, distribution and selling.


Log in to reply