#crc32

Esta funcion nos devuelve el calculo del crc32 de una cadena de texto. Espero les sea de utilidad!

Bienvenidos sean a este post, hoy veremos una funcion de PHP. Esta funcion devuelve el calculo del polinomio crc32 de una cadena de texto. Veamos como es su sintaxis: crc32(texto); Simplemente le pasamos el texto y este nos devolvera el valor. Un detalle a tener en cuenta, si lo utilizan en ordenadores de 32 bits puede devolver un valor negativo si utilizan a echo para mostrarlo. Esto es asi…

在 Hacker News Daily 上看到「The image in this post displays its own MD5 hash (retr0.id)」這篇，作者想要產生一張 PNG 圖，這張圖的 MD5 值就在圖片上呈現。然後作者本人有出現在 Hacker News 討論串上面，提到流量撐不住，所以丟到 Twitter 上面 (而很幸運的，Twitter 沒有壓這張圖，是保留原圖，所以可以驗證 MD5)： The image in this tweet displays its own MD5 hash. You can download and hash it yourself, and it should still match – 1337e2ef42b9bee8de06a4d223a51337 I think this is the first PNG/MD5…

This writeup will be an example in using angr to “automatically” solve this problem. But along the way, we’ll find two deficiencies in angr, and show how to fix them! Beyond being a writeup of this problem -- there is very little information specific to this challenge -- this can serve as an angr use and development tutorial.

Challenge:

We are given a file cricket32.S, which contains 32-bit x86 assembly and instructions for assembling:

// gcc -m32 cricket32.S -o cricket32 .text str_usage: .string "Usage: ./cricket32 flag\nFlag is ascii with form uiuctf{...}\n" str_yes: .string "Flag is correct! Good job!\n" str_nope: .string "Flag is not correct.\n" .global main main: mov $str_usage, %ebx xor %esi, %esi SNIP jmp printf

Note that the -m32 flag will force gcc to compile a 32-bit executable. The assembly is pretty short, but has a few hard-to-interpret instructions, such as aaa (ASCII Adjust After Addition), sahf (Store AH into Flags), and so on. It's possible these are filler meant to distract; it's also possible that they're being used as part of some bizarre check, or as data (if the program is reading its own code).

Approach

Instead of trying to reverse engineer this ourselves, we'll be using angr to solve for the input. For background, angr is a tool that turns the problem of "get this program into this particular state" into a constraint problem. We interact with angr mostly through the functions explore(), which tells to seek out various states (such as printing "Success!"), and add_constraints(), which let us tell angr rules about the input or states of the program. Let's dive in!

After compiling cricket32, we open it up in IDA to see what addresses we might care about:

We see that if the code reaches 0x12BD, it will load str_nope, and then proceed straight to loc_12BC and printf. This is our failure condition. We'll load the binary in angr and tell to find an input that allows us to avoid that address, 0x12BD.

import angr import claripy project = angr.Project("./cricket32", auto_load_libs=True) flag_len = 32 arg1 = claripy.BVS('arg1', flag_len*8) initial_state = project.factory.entry_state(args=["./cricket32", arg1])

Here arg1 is our symbolic representation of the argument to the binary. We've allocated 32 bytes to (flag_len), hoping this is enough. Since arg1 can have zero-bytes, effectively being shorter than 32, this will work as long as the flag is at most 32 bytes long.

Running the above code produces the output:

WARNING | 2020-07-19 20:08:15,647 | cle.loader | The main binary is a position-independent executable. It is being loaded with a base address of 0x400000.

so the address that we wanted to avoid, 0x12bd, will actually be 0x4012bd. Let's now explore for that address:

sm = project.factory.simulation_manager(initial_state) sm.explore(avoid=[0x40128D])

Unfortunately, we are left with the result <SimulationManager with 26 avoid (7 errored)>. When angr explores paths, it has a few different "stashes" that paths can be in. There are:

active: paths that have not been fully explored yet

deadended: which is paths that terminated the program

avoid: paths that reached somewhere we didn't want it to

found: paths that found an explicit destination request (we gave no such destination here)

errored: indicating that angr was unable to continue with a path.

Ideally we would have had a deadended path here, meaning that a program successfully terminated without reaching the avoided point of 0x4012bd. Since we didn't, let's take a look at the errors.

sm.errored[0] will get the first state in the errored stash, and on the console we get:

<State errored with "IR decoding error at 0x4012a2. You can hook this instruction with a python replacement using project.hook(0x4012a2, your_function, length=length_of_instruction).">

What's 0x4012a2? Looking in IDA again, we see the crc32 edx, dword ptr [esi] instruction. The crc32 instruction is used to compute a cyclic redundancy check. This is a somewhat complicated operation, and generally rare, so it's not terribly surprising that angr doesn't know how to translate it into constraints. As suggested, we can implement a hook to emulate this.

Angr Hooks

A hook in angr is used to modify or replace a piece of code. A syscall instruction may, for instance, invoke some complicated kernel behavior, and hooking it could allow us to substitute our own behavior; or a simple call might be hooked to modify the execution. When writing a hook, it is important to remember we are working with symbolic values, not actual integers, so that we ultimately return a mathematical expression representing the modified state.

Our hook will intercept the crc32 instruction, emulate it, and then return control flow at the end of the instruction. The crc32 instruction is 5 bytes long, so our hook starts:

def crc32_hook(state): pass project.hook(0x4012a2, crc32_hook, length=5)

Next we need to implement the correct behavior. Since all computations must be symbolic, we can't just use a library implementation of CRC32. Additionally, most CRC32 implementation use the "CRC-32" specification, with the 0x04C11DB7 polynomial (essentially a magic number). The x86 crc32 instruction instead uses the "CRC-32C", or "Castagnoli", specification, with the 0x1EDC6F41 polynomial. Some googling turns up this implementation of CRC-32C we can adapt.

CRC_TABLE = ( 0x00000000, 0xf26b8303, 0xe13b70f7, 0x1350f3f4, # ... SNIP ... 0xbe2da0a5, 0x4c4623a6, 0x5f16d052, 0xad7d5351, ) table_dict = {i: claripy.ast.bv.BVV(CRC_TABLE[i],32) for i in range(256)} def get_crc32_table_BVV(i): i = i.to_claripy() return claripy.ast.bool.ite_dict(i, table_dict, 0xFFFFFFFF) def crc32c(dst,src): b32 = src crc = dst for i in [3,2,1,0]: b = b32.get_byte(i) shift = (crc >> 8) & 0x00FFFFFF onebyte = crc.get_byte(3) crc = get_crc32_table_BVV(onebyte ^ b) ^ shift return crc

Here we need to do a symbolic table lookup, which we can implement with ite_dict. ite_dict(i, table_dict, 0xFFFFFFFF) means that we use the key-value pairs in table_dict to look up i; the default value will be 0xFFFFFFFF is not in the dict (but in our case it always will be). Then our crc32c method computes the update to running CRC32 dst using the four bytes in src. Our hook is then:

def crc32_hook(state): crc = state.regs.edx addr = state.regs.esi b32 = state.memory.load(addr).reversed print('CRC32 accessing ',b32) state.regs.edx = crc32c(crc, b32)

This clearly not a drop-in replacement for any crc32 instruction: we've hard-coded that the source operand is dword ptr [esi] and our destination is edx. But that will work for our purposes here. After adding our hook, we reload the initial state and explore as before. The search continues for a few seconds, until we get a very long stack trace that eventually ends:

RecursionError: maximum recursion depth exceeded while calling a Python object

Urk.

Removing recursion

This turns out to stem from a shortcoming of how ite_dict is implemented. It passes the dictionary to ite_cases, which loops a claripy.If expression -- essentially a ternary operator. In our case, this produces an expression like

claripy.If(i == 0, 0x00000000, claripy.If(i == 1, 0xf26b8303, claripy.If(i == 2, 0xe13b70f7, claripy.If(i == 3, 0x1350f3f4, ... <255 levels like this> ))))

and when Z3 (the backend constraint solver) tries to analyze this, it balks at the depth of the expression. There are two options now: (1) implement a better version of ite_dict, or (2) use a table-free imeplemtation of CRC-32C. In the competition, we used option (2). Googling some more for how to generate the table leads us to this page on generating the table. Instead of generating a table and storing it, we can just "recompute" (symbolically) the value each our crc32 instruction is hit. This leads to the code,

def get_crc32_calc_BVV(i): crc = i.zero_extend(32 - i.size()); if isinstance(crc, angr.state_plugins.sim_action_object.SimActionObject): crc = crc.to_claripy() for j in range(8): shift = ((crc >> 1) & 0x7FFFFFFF) cond = crc & 1 > 0 crc = claripy.If(cond, shift ^ 0x82f63b78, shift); return crc

The crc.to_claripy() here is necessary in case angr passes us a SimActionObject instead of an actual symbolic value. Then the rest of the operations work just like the C code in the link above, with the claripy.If replacing C's ternary operator. Then we replace the appropriate line in our crc32c function to use get_crc32_calc_BVV instead of get_crc32_table_BVV. Looking at our code so far:

import angr import claripy #copy implementation from https://medium.com/@chenfelix/crc32c-algorithm-79e0a7e33f61 def get_crc32_calc_BVV(i): crc = i.zero_extend(32 - i.size()); if isinstance(crc, angr.state_plugins.sim_action_object.SimActionObject): crc = crc.to_claripy() for j in range(8): shift = ((crc >> 1) & 0x7FFFFFFF) cond = crc & 1 > 0 crc = claripy.If(cond, shift ^ 0x82f63b78, shift); return crc def crc32c(dst,src): b32 = src crc = dst for i in [3,2,1,0]: b = b32.get_byte(i) shift = (crc >> 8) & 0x00FFFFFF onebyte = crc.get_byte(3) crc = get_crc32_calc_BVV(onebyte ^ b) ^ shift return crc def crc32_hook(state): crc = state.regs.edx addr = state.regs.esi b32 = state.memory.load(addr).reversed print('CRC32 accessing ',b32) state.regs.edx = crc32c(crc, b32) project = angr.Project("./cricket32", auto_load_libs=True) flag_len = 32 arg1 = claripy.BVS('arg1', flag_len*8) initial_state = project.factory.entry_state(args=["./cricket32", arg1]) sm = project.factory.simulation_manager(initial_state) project.hook(0x4012a2, crc32_hook, length=5) sm.explore(avoid=[0x40128D])

At the end we are left with: <SimulationManager with 6 deadended, 33 avoid>. Fantastic! That means 6 paths successfully terminated without hitting 0x4012bd. Each of these SimStates are listed in sm.deadended. To get the input, we can call state.make_concrete_int(arg1), which will return arg1 as a big integer; then .to_bytes(32,"big") to turn it into a string:

>>> for state in sm.deadended: ... state.make_concrete_int(arg1).to_bytes(32,"big") ... b'uiuc\xdbK\xdf\x9d\xf0N\xd6\x95cket_a_c\xddL\xc7\x97it}\x00\x00\x00\x00\x00' b'\xdaD\xd1\x9ftf{a_cricket_a_c\xddL\xc7\x97\xc6Y\xd9\xfc\x00\x00\x00\x00' b'uiuctf{a\xf0N\xd6\x95\xccF\xc1\x88_a_crack\xc6Y\xd9\xfc\x02\x00\x00\x00' b'\xdaD\xd1\x9f\xdbK\xdf\x9d\xf0N\xd6\x95cket_a_c\xddL\xc7\x97\xc6Y\xd9\xfc\x10\x10\x00\x00' b'\xdaD\xd1\x9ftf{a_cri\xccF\xc1\x88\xf0L\xfb\x9frack\xc6Y\xd9\xfc \x01\x00' b'uiuctf{a\xf0N\xd6\x95\xccF\xc1\x88_a_c\xddL\xc7\x97\xc6Y\xd9\xfc\x01\x04\x01\x08'

We see that angr has found 6 solutions that technically would work as input to the program, and indeed several start with uiuctf{ -- a sign we're on the right track! But they're filled with non-printable characters. The astute eye might piece together the flag from the above malformed fragments, but the "right" thing to do is to do tell angr that each byte of input will be printable ASCII (or zero).

Cleanup

for b in arg1.chop(8): initial_state.add_constraints((b == 0) | ((b > 31) & (b < 127))) for i in range(len("uiuctf{")): b = arg1.chop(8)[i] initial_state.add_constraints(b == ord("uiuctf{"[i]))

It's important to note that -- perhaps a bit surprisingly -- compound constraints are formed using | and &, not Python's or and and keywords. arg1.chop(8) breaks the 256-bit vector arg1 into a list of 8-bit bytes, and we add a constraint for each byte. The second loop actually forces that the flag starts with uiuctf{. Probably not strictly necessary, but will definitely accelerate solving. This code gets inserted right before initial_state = project.factory.... The evaluation now takes less than a minute, and ends with

<SimulationManager with 1 deadended, 26 avoid> >>> >>> for sol in sm.deadended: ... print(sol.posix.dumps(1)) ... sol.make_concrete_int(arg1).to_bytes(32,"big") ... b'Flag is correct! Good job!\n' b'uiuctf{a_cricket_a_crackit}\x00 @@\x00'

Flag get!

A reality check

In practice, progress wasn't quite this linear. Some gotchas I encountered were:

Needing to use .to_claripy() in the hook -- if you don't, the hook runs fine, and then you get weird and inscrutable errors later.

Figuring out what the recursion error was coming from. Was determined by shrinking the dictionary size and watching the problem go away (although of course no solution was found).

Lots of byte-ordering issues. angr will often store the bytes the opposite order you expect, so e.g. forcing the string to start with uiuctf{ was something initally done backwards.

LOTS more byte-ordering issues in implementing the CRC. And sign-bit madness. If you think translating bit-fiddly C code to Python is bad, try translating bit-fiddly C code to symbolic Python with unusual endianness.

This program is small enough that it might have been very routine to solve with angr in just a few lines of code, or that IDA might have decompiled it into something very readable. angr was thwarted by the crc32 instruction. It is worth noting that, had the binary been 64-bit, angr would have known how to do a CRC32; 32-bit executables are less supported. And IDA refused to parse the main code chunk as a function, because it couldn't handle the jump-to-the-middle-of-an-instruction we see at 0x12ba. IDA already parsed an instruction at 0x1278, so a jump to 0x1279 broke it. Finally, the ASCII-Adjust operations (aaa) are pretty rare, and I was surprised that angr supported them. I doubt many decompilers would.

Postscript: A better ite_dict

During the competition, I use a loop implementation of CRC-32 that didn't use a table. In practice, there's little reason why a table couldn't be used, if the if-then-else statement went in a binary tree instead. So I wanted to try that too! Code:

#Improved version of ite_dict that uses a binary search tree instead of a "linear" search tree. #This improves Z3 search capability (eliminating branches) and decreases recursion depth: #linear search trees make Z3 error out on tables larger than a couple hundred elements.) # Compare with https://github.com/angr/claripy/blob/f2c1998731efca4838a4edb9dec77e0424c5f691/claripy/ast/bool.py#L164 def ite_dict(i, d, default): i = i.ast if type(i) is claripy.ast.base.ASTCacheKey else i #for small dicts fall back to the old implementation if len(d) < 4: return claripy.ast.bool.ite_cases([ (i == c, v) for c,v in d.items() ], default) #otherwise, binary search. #Find the median: keys = list(d.keys()) keys.sort() split_val = keys[len(keys)//2] #split the dictionary dictLow = {c:v for c,v in d.items() if c <= split_val} dictHigh = {c:v for c,v in d.items() if c > split_val} valLow = ite_dict(i, dictLow, default) valHigh = ite_dict(i, dictHigh, default) return claripy.If(i <= split_val, valLow, valHigh) def get_crc32_table_BVV(i): i = i.to_claripy() return ite_dict(i, table_dict, 0xFFFFFFFF)

With this modified version of get_crc32_table_BVV, the table-based code ran fine. Interestingly, it took several minutes to solve -- quite a bit slower than the "slow" and "complicated" loop-based implementation. In general though, I expect the binary tree would be faster for Z3 to analyze than a linear expression. I've created a pull request to get this improvement into angr, hopefully. :)

New Post has been published on http://suporteninja.com/1-parte-da-entrevista-com-david-ben-svaiter-expert-em-criptografia-assimetrica/

1° parte da entrevista com David Ben Svaiter expert em Criptografia Assimétrica

Nesse rápido bate bola com David Ben Svaiter Diretor da Área de Desenvolvimento de Softwares e Segurança da Informação da BigBlue, Expert em criptografia digital com algoritmos de chaves simétricas 1° parte da entrevista com David Ben Svaiter expert em Criptografia Assimétrica

David Ben Svaiter é Diretor da Área de Desenvolvimento de Softwares e Segurança da Informação da BigBlue, Expert em criptografia digital com algoritmos de chaves simétricas, com responsabilidade de coordenar todo o desenvolvimento deste segmento. Responsável por estudos e planejamento de processos de negócios envolvendo área de desenvolvimento de sistemas. Responsável por novas soluções, personalizadas para clientes prioritários. Engenheiro de sistemas online e offline, coordenando a equipe destes segmentos. Coordenador e revisor de projetos diversos. Consultoria especializada em criptografia e desenvolvimento de sistemas particularizados.

(David é também o líder do time de desenvolvimento da BigBlue que projetou o Software nacional de criptografia CifraExtrema, que falamos aqui no Suporte Ninja) 

Você poderia explicar para pessoas “normais” o que é criptografia?

  Resposta: A palavra vem do grego kryptós (esconder) e graphein (escrita).

É o conjunto de técnicas que objetivam esconder informação daqueles que não possuam os meios corretos para abri-la. Já em 500 aC os hebreus utilizavam esta técnica (algoritmo Ashbat) para trafegar informações (escritas nesta época) entre os seus, sem que invasores ou ameaças de todo tipo pudessem compreender o conteúdo da mensagem. Foi disseminada pelo Império Romano, que utilizando técnicas de substituição monoalfabética, permitia que mensageiros trafegassem informações militares por linhas inimigas durante as campanhas de ocupação e domínio, utilizando tiras de couro amarrada aos seus braços (Cifra de César).

Durante a 2ª Grande Guerra, os alemães tiveram por muito tempo a supremacia do cenário bélico pois usavam uma criptografia altamente elaborada em todas as suas comunicações escritas e de rádio (algoritmo Enigma), impedindo os Aliados de descobrir as táticas e ordens, antes e durante as batalhas. E foi justamente a quebra do Enigma por Alan Turing que permitiu que os Aliados soubessem de antemão os planos e táticas do Eixo, antecipando-se e preparando-se convenientemente à retaliação.

A criptografia, portanto, acompanha a humanidade há mais de 2000 anos, não sendo exclusiva da forma digital. A diferença fundamental é que, sendo os computadores muito mais rápidos que o ser humano, exige que os algoritmos sejam também refinados e fortalecidos contra esta velocidade – o que, entretanto, não é uma tarefa nem simples nem fácil, sendo um ramo específico da matemática avançada.

No mundo da criptografia se fala muito em Hash, É uma forma de criptografia? Qual a utilização delas no mundo do desenvolvimento?

  Tabelas HASH são cálculos matemáticos que permitem produzir resultados específicos para determinado conteúdo, funcionando como “validadores da integridade de uma informação”. Um algoritmo HASH produz combinações quase exclusivas (vide mais abaixo) para qualquer informação, funcionando como verdadeira “assinatura digital” desta informação.

Se qualquer letra ou ponto ou espaço da informação for trocada, ou mesmo apenas a posição dela for alterada, a assinatura irá também ser modificada em sua totalidade. Um exemplo de um HASH de 2 bytes é o “dígito verificador” do CPF. Todo número de CPF gera uma “assinatura” (ou HASH) de 2 dígitos ao final, garantindo que o número anterior (a informação portanto) corresponde a uma informação válida.

Existem diversos algoritmos “validadores de informação”: CRC32, CRC64, SHA1, SHA256, SHA512, Whirlpool512, etc. Os números que normalmente os acompanham referem-se ao número de bits que a “assinatura” contém.

Lembrando que 1 byte (letra, dígito ou símbolo) equivale a 8 bits, o CRC32 gera uma assinatura de 4 bytes (32 bits ÷ 8), o CRC64 gera uma assinatura de 8 bytes (64 bits ÷ 8), enquanto o SHA512 gera uma assinatura de 64 bytes (512 bits ÷ 8). O tamanho da assinatura (2 digitos no CPF e 64 dígitos no SHA512) determina o grau de confiabilidade no conteúdo da informação, baseado no número de possibilidades contra colisão.

Chamamos de colisão a propriedade de um algoritmo HASH gerar o mesmo número para dois conteúdos diferentes – o que poderia significar que determinada informação poderia ser falsificada. Num algoritmo de 2 dígitos como o do CPF (módulo 11), o HASH possui um máximo de 100 ocorrências (0 – 99), o que permite grande número de colisões – afinal, temos apenas um “espaço” de 100 números para definir toda e qualquer informação, de qualquer tamanho. Por isso este tipo de algoritmo não deve ser utilizado em sistemas digitais de maior complexidade, já que as chances de uma falsificação/colisão são bastante factíveis.

Já em um algoritmo de 512 bits, o número de possibilidades para encontrarmos uma colisão é calculado como sendo 2256 -1 (algo como 115.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000 possibilidades), o que inibe colisões de forma eficaz.

Por isso afirmamos também que algoritmos HASH produzem combinações “quase exclusivas”, pois é uma certeza matemática que colisões podem existir, apesar de extrema e absurdamente improváveis no cotidiano, mesmo considerando todos os textos existentes no mundo.

Portanto, cálculos do tipo HASH servem para “assinaturas digitais”, já que sempre que calcularmos determinada informação teremos o mesmo resultado e, qualquer modificação que seja feita em no conteúdo da informação, irá modificar o resultado HASH.

Apenas como exemplo, seguem as assinaturas dos textos abaixo, calculadas em SHA1 (128 bits), aqui representado na forma hexadecimal:

Suporte Ninja =  FAE24DAF7C9BA0DD73FE15EAD6A89F91E2E8C6B7

Suporte-Ninja = E883EC1BC378113E501CAEDAA2761F54A3A51328

ABCDE = 7BE07AAF460D593A323D0DB33DA05B64BFDCB3A5

ABCED = 77B7E3A8AE28A8EF15D242732C752218FD3B7537

Entretanto, algoritmos HASH não podem ser utilizados como criptografia, já que são chamados “one-way” (mão única), não permitindo sua reversão (ou decodificação). Não temos como, partindo de uma assinatura HASH, descobrir qual o conteúdo original que ela corresponde.

Diferentemente de algoritmos criptográficos, que permitem esconder a informação mas ter acesso à ela (ao original), caso conheçamos a fórmula e a chave usada para codifica-la.

ENCODE e CRIPTOGRAFIA são a mesma coisa? Explique a diferença.

Resposta: A grosso modo sim, mas existe uma diferença fundamental entre eles. Algoritmos de codificação (encode) buscam apenas reduzir o tamanho do dado original (ex. RLE, ZIP, etc) e/ou compatibilizá-lo entre vários sistemas diferentes (ex. Base64), em geral nem utilizando uma “chave secreta” para esta operação mas apenas uma formulação matemática (um algoritmo).

Já a criptografia procura esconder a informação e, portanto, busca auxilio não só numa formulação complexa (o algoritmo) mas também no uso de “chaves”, parcelas secretas que participam da fórmula, impedindo que aqueles que não as conheçam sejam impedidos de ter acesso à informação original.

As chaves criptográficas não são, como a maioria das pessoas pensa, senhas de acesso a um processo ou sistema. São consideradas parte integrante do cálculo matemático e devem ser trabalhadas internamente no algoritmo, objetivando esconder de um cripto-analista, qual foi a chave original informada.

Lembro que a chave é a parcela mais importante de qualquer algoritmo! Não adianta o algoritmo ser complexo se a chave é fraca. Entretanto, a recíproca não é verdadeira: algoritmos simples podem ser inquebráveis se a chave for altamente complexa – o que entretanto traz uma dificuldade enorme em memorizá-la ou mesmo transmiti-la ao destinatário autorizado.

É justamente o equilíbrio entre o algoritmo e a chave que faz o desenvolvimento de um algoritmo de criptografia ser algo extremamente sofisticado e matematicamente desafiante. Saliento que não é um trabalho para amadores, pois temos ainda a cripto-análise (o inverso da criptografia), a ciência que provê a capacidade de descobrir uma informação sem conhecer o algoritmo e a chave, mesmo em algoritmos inicialmente considerados complexos e com chaves de tamanho considerável.

Base64 ainda é utilizada em muitas tecnologias! Base64 é uma forma de criptografia?

  Resposta: Se considerarmos apenas a língua portuguesa, “codificar” ou “criptografar” são a mesma coisa. Mas se focarmos isso no âmbito da ciência da criptografia, podemos distinguir ambos pelo uso ou não de chaves criptográficas.

Portanto, não podemos considerar NENHUM algoritmo de “encode” como sendo um algoritmo de criptografia, já que qualquer pessoa tem acesso à informação – e isso não a protege de forma alguma.

No caso do algoritmo Base64, basta aplicar a fórmula para podermos codificar e decodificar a informação, sem uso de nenhuma chave-secreta. Mas, se utilizarmos uma maneira de aplicar uma “chave” após esta codificação, impedindo que a fórmula original decodifique corretamente o dado, estaremos então migrando para um algoritmo criptográfico.

Parece simples conceitualmente, mas como disse antes, é muito difícil fazer isso de forma que o dado criptografado resista às técnicas de criptoanálise, que podem descobrir o dado sem conhecer o algoritmo ou mesmo a chave-secreta utilizada. Criptografia não é trabalho de amadores.

Em suas postagens no grupo de Criptografia do Linkedin e aqui no Suporte Ninja você fala muito em criptografia O que é CRIPTOGRAFIA SIMÉTRICA?

  Resposta: Algoritmos de Chaves Simétricas são algoritmos criptográficos que utilizam a mesma chave para codificar e decodificar a informação (simetria entre a chave que fecha e a que abre a informação). São os algoritmos mais antigos utilizados (não confundir ANTIGO com OBSOLETO, FRACO ou INSEGURO!) e possuem uma dificuldade comum a todos: como informar a chave ao destinatário?

No âmbito da criptografia profissional, estimamos um cenário “ideal” de sigilo e vigilância, pressupondo que estamos completamente grampeados: nosso telefone, nosso computador, nosso smartphone, até mesmo as cartas que enviamos pelo Correio. Tudo é vigiado. Portanto, se precisamos neste cenário enviar uma informação codificada a outros, como fazer para informa-los qual a chave-secreta foi utilizada e que permitirá a decodificação do dado, sem que aqueles que nos vigiam tenham acesso à ela?

Este é um “calcanhar de Aquiles” de toda criptografia de algoritmo de chaves simétricas, o que estimulou por séculos a criação de uma maneira SEGURA de fazê-lo.

E durante o século XX, dois matemáticos (Diffie e Hellman) chegaram a uma solução, como veremos mais abaixo.

Você costuma dizer em suas postagens no seu grupo Criptografia do Linkedin sobre as vantagens do uso de criptografias assimétricas. Você pode explicar o que é CRIPTOGRAFIA ASSIMÉTRICA?

  Resposta:  Algoritmos de Chaves Assimétricas são algoritmos que usam chaves diferentes para codificar e decodificar o dado.

Tais algoritmos são extremamente difíceis de se construir (apesar do conceito ser de fácil entendimento) e pode-se dizer que foi, durante séculos, o Graal da criptografia. Até hoje existem basicamente 3 algoritmos deste tipo: Diffie-Hellman (conceitualmente o mais utilizado, como no PGP, GnuPG, TrueCrypt, etc.), RSA (criado por Shamir, Adler e River e de uso comercial) e El-Gammal (outro algoritmo de uso comercial).

Sua formulação segue o conceito de multiplicação de números primos enormes (mais de 1000 dígitos por exemplo), obtendo-se um resultado também primo, que não pode ser fatorado em tempo hábil (ter as chaves descobertas). Mais recentemente, vemos algoritmos assimétricos trabalhando com Curvas Elípticas em Campos Finitos (Curve25519, ECC, entre outros), que possuem outros esquemas de cálculo da chave baseado em localização de pontos em curvas elípticas.

Conhecidos como “algoritmos de chaves públicas/privadas” (ou PKI – Public Key Infrastructure), tem como principal vantagem a possibilidade de se passar uma informação codificada a um destinatário, sem o risco de um interceptador abrir o dado – pelo menos em teoria. Na prática, tem se mostrado falho em ambientes de monitoramento completo (como em uma rede espionada), nos casos de invasão do equipamento (obtendo-se a chave privada do usuário) ou em ataques à Autoridade Certificadora (veja explicação a seguir), obtendo-se as chaves pública e privada do usuário em alguns casos.

Além disso, exigem mecanismos que fiscalizem e evidenciem que os usuários que se “apresentam” pela chave pública sejam validados, exigindo o uso de “certificadoras” (como Verisign, Certisign, Serasa, etc), sem as quais, qualquer um poderia se passar por um usuário legítimo; como se você se apresentasse como sendo o Silvio Santos da TV).

Matematicamente, uma chave assimétrica é menos segura que uma chave simétrica de mesmo tamanho. Para se obter a segurança equivalente a uma chave simétrica de 128 bits, a criptografia PKI necessita de uma chave pública de 3072 bits e uma privada de 256 bits, enquanto uma chave RSA deverá possuir ambas em 3072 bits de tamanho, enquanto uma chave do tipo Curva deverá possuir pelo menos o dobro do tamanho (256 bits).

 Quais as vantagens da criptografia SIMÉTRICA em relação à criptografia ASSIMÉTRICA?

  Resposta: Vejo como inúmeras as vantagens da criptografia de chaves SIMÉTRICAS em relação à de chaves ASSIMÉTRICAS:

  Velocidade. Algoritmos de chaves simétricas são muito mais velozes que os de chaves assimétricas, pois não precisam efetuar multiplicação de gigantescos números primos.

São mais seguros pois suas chaves são mais seguras e o algoritmo não depende de números primos.

Algoritmos simétricos não estão limitados à forma de cálculo, nem ao tamanho da chave criptográfica.

A questão do “envio seguro de uma chave” pode ser ultrapassado com esquemas diversos: através de canal paralelo (protegido ou não), ou através de outras formulações criativas e eficazes.

Algoritmos de chaves assimétricas são bons para AUTENTICAR pessoas – mas para a criptografia da informação, os principais programas deste tipo utilizam algoritmos simétricos (como AES, Twofish, IDEA, entre outros). Isso evidencia o que os próprios fabricantes acham do conceito. Entretanto, vemos hoje algoritmos simétricos sendo usados também para autenticar pessoas através de esquemas sofisticados porém altamente eficientes, rápidos e eficazes.

A segurança de qualquer algoritmo reside no fato de que, para se descobrir as chaves utilizadas e abrir a informação, gasta-se muito mais energia elétrica (e dinheiro) que o valor da informação. Apenas como referencial, em 1980 (data de sua disseminação com o PGP principalmente) estimava-se isso a alguns bilhões de dólares, alguns GigaWatts de energia e muitos, muitos milhares de anos. Hoje, com computação paralela em nível de hardware e software, placas multiprocessadas com até 8192 GPU´s de alta performance e formulações que visam substituir a fatoração de primos (como Curva de Sieve), podemos estimar como uma fração de tempo e custo a descoberta de uma chave assimétrica; que pode até mesmo ser substituído por esquemas muito baratos (e até triviais) de monitoramento e vigilância de equipamentos e redes (ponto x Certificadora), obtendo da mesma forma as chaves utilizadas, sem necessidade de calculá-las.

Este mesmo conceito de gasto se aplica aos algoritmos de chaves simétricas. Há vários ataques que podem ser utilizados em algoritmos simétricos objetivando poupar tempo, energia, recursos. Mas em se tratando de um algoritmo matemática e criptograficamente seguro, ele já os prevê, restando apenas o Ataque por Força Bruta, que define e quebra todo e qualquer algoritmo, presente ou futuro. Neste tipo de ataque, todas as chaves possíveis são testadas, o que dependendo do algoritmo, significa um enorme gasto de tempo e energia (lembrando que este gasto deve compensar o valor da informação a ser quebrada). Apenas para um parâmetro, algoritmos simétricos de 256 bits com chaves de 256 bits pressupõem algo como 11575 possibilidades de chave. Se tentarmos gerar 1 quatrilhão de chaves por segundo (uma medida superavaliada mesmo com os recursos hoje disponíveis como acima citado), devemos varrer todas as possibilidades em 1,13132 anos. Impraticável.

Finalizo perguntando: porque as Agências de Inteligência e o ambiente de alta criticidade Militar usam algoritmos de chaves simétricas e não esquemas assimétricos?

   Criptografar uma informação já criptografada com outro algoritmo traz alguma camada extra de segurança?

  Resposta:  Não.

Como são fórmulas matemáticas de alta complexidade e como normalmente trabalham com esquemas semelhantes nos bits da informação (transposição & substituição), o uso de dupla-camada de criptografia, seja com um mesmo algoritmo usando chaves diferentes, seja com algoritmos diferentes usando ou não a mesma chave, pode vulnerabilizar a criptografia do primeiro algoritmo. E isso é comprovado na prática, através de análises diversas (entropia de Shannon, Bi e TrésBi-Entropia, Análise de Frequência, Relação entre Vogais e Consoantes, testes diversos de repetição de bits, etc.).

Um bom e SEGURO algoritmo criptográfico, que obtenha bons índices nos testes acima apontados, já é mais que suficiente para proteção da informação.

Porque os certificados de segurança estão na faixa de 128 a 256 bits enquanto os Ramsonwares usam chaves superiores?

Resposta: Basicamente o “Ramsonware” não utiliza chaves assimétricas para criptografia dos dados, mas apenas para “identificar seus autores” quando em operações de “C & C” (comando e controle). Neste caso, as chaves são também de 128 ou 256 bits, quando muito.

Para a criptografia, estas pragas utilizam algoritmos de chave simétrica, onde não há limite preestabelecido.

Chamo a atenção também para o fato de esquemas PKI (chaves assimétricas ou públicas/privadas) precisam ser estocadas em uma ou mais Autoridades Certificadoras (cadeia de certificação), o que pode demandar alta taxa de transferência e estocagem, quando multiplicamos cada chave por milhares ou milhões de usuários.

A TOR é segura ou não? Em suas postagens você afirma categoricamente que não. E se usarmos a TOR com ferramentas que bloqueiam scripts, cookies e publicidades, não estaríamos criando mais uma camada de segurança?

Resposta: A rede TOR é segura desde que todos os nodes (os nós da rede por onde a informação passa) forem seguros. E isso não é o que vimos recentemente.

Já existem esquemas conhecidos de falsificação de nós na rede, que possibilitam identificar tanto o emissor, quanto o destinatário e a informação em si. A questão é: isso possui um custo, que vem caindo a cada dia (hardware + software + energia para tal). Somado ao fato de que a TOR possibilitou um enorme número de atos ilícitos nos últimos meses (tráfico de drogas e armas, pedofilia, planejamento de crimes, venda de informações patenteáveis, etc.), temos enormes estruturas e muito dinheiro sendo investido em monitorá-la e quebrá-la – o que em minha opinião já foi feito.

Prova disso é a prisão, feita pelo FBI, de componentes que a utilizavam para perpetrar tais crimes.

Em meu grupo CRIPTOGRAFIA BRASIL tenho alguns documentos e reportagens que citam tais vulnerabilidades, incluindo a compra por USD 1 milhão pelo FBI, de um esquema desenvolvido pela Carnegie Melon para “minar” a rede – e sabe-se hoje que o esquema funcionou e é eficaz, pois foi o que possibilitou a identificação e prisão de criminosos.

E quanto a este exemplo de esteganografia?    O Pablo ou RootsBabilonia andou se aventurando no Hellboundhackers.org e disse que isso é muito sinistro. Isso é algo como uma mensagem convertida em uma base e depois em uma representação visual “Pseudo-Alienígena”. Por se tratar de uma imagem deixa os ataques de força bruta tradicionais muito mais difíceis, entre os participantes que quebravam até algumas criptografias customizadas, só uma minoria conseguiu ler a mensagem escondida nessa imagem! Conceitos simples porem criativos como esses não poderiam  deixar as “coisas” mais seguras?

Essa imagem faz parte de uma serie de desafios de segurança de criptografia do Wargame HellboundHackers

Resposta:Esta imagem não é esteganografia, mas apenas uma forma de tentar esconder caracteres em um formato diferenciado: seja como símbolos, seja por ilusão de ótica – como vemos em textos escritos de cima para baixo, imitando japonês. Lembro ainda que mesmo que as palavras sejam mudadas por símbolos (e ainda assim não é criptografia mas hierografia), ainda pode ser quebrada por criptoanálise. Conceitualmente válido, mas na prática mostra-se ineficaz.

  A esteganografia é um pouco desdenhada no desenvolvimento de soluções em busca de privacidade. Mas esta também não é uma poderosa forma de esconder informação?

Resposta: A esteganografia é a arte de esconder informação entre os pontos de uma imagem (pixels), espalhando a informação em distribuição uniforme ou aleatória, impedindo que nossos olhos percebam, entre milhares de pontos, aqueles que “escondem” uma informação.

A questão é que ela é bastante limitada em eficácia, já que traduz a informação em pontos coloridos na imagem, onde cada “letra” é traduzida numa “cor” e uma posição – e isso pressupõe que, para se obter sucesso, precisemos de uma imagem CHEIA destas cores para que a informação passe desapercebida.

Logo, o tamanho e qualidade da imagem onde a informação será escondida precisa ser, tecnicamente, muito apropriada a cada tipo de informação (possuindo pontos e cores suficientes para que os pontos e cores “criptografados” sejam corretamente escondidos). E isso, na prática, NUNCA ocorre com 100% de eficácia, o que permite que descubramos a informação.

Seguindo este modelo, onde há diferença nítida entre a informação escondida na imagem, existem algoritmos que trabalham comparando as cores de todos os pontos vizinhos, descobrindo com alto grau de eficácia (90%-100%) a informação espalhada na imagem. Ou seja, mesmo que usemos uma informação pequena (“Suporte-Ninja”) dentro de uma imagem imensa (10 megapixels), o algoritmo de criptoanálise rapidamente descobre a informação. E isso fica ainda mais simples se a imagem for JPG ou GIF ou qualquer outro padrão “comprimido”, justamente por esta característica.

Interessante notar que, uma vez codificada, a imagem não pode ser transformada em JPG ou outro padrão qualquer, pois isso destruiria a informação original, alterando as cores (os códigos) nela inseridos!

Além disso, como os pontos são “cores”, existe um limite muito claro entre sua quantidade e a quantidade total de pontos da imagem original para que a informação passe desapercebida. Estimo que este número seja da ordem do milésimo, ou seja, 1 ponto para cada 1000 pontos de imagem. Assim, o limite do que podemos “esconder ou informar” dentro de uma imagem é muito, muito menor do que conseguimos fazer usando a criptografia clássica, simétrica ou assimétrica! E mesmo assim, será descoberta.

Portanto, a esteganografia é muito interessante do ponto de vista teórico, mas muito simples de ser descoberta (encontrada na imagem) ou mesmo “destruída” (via conversão e desconversão de padrões gráficos) sem que se destrua o dado transmitido (a imagem em si), ou seja, sem que o destinatário perceba que está sendo interceptado! E esta característica é fundamental ao sucesso da interceptação, pois se eles percebem, mudam a forma e o canal de transmissão da informação. Foi justamente esta característica que permitiu aos Aliados vencerem o Eixo na 2ª Grande Guerra – os alemães não percebiam que suas mensagens estavam “sendo lidas” e acreditavam que trafegavam tudo em completa privacidade!

E por isso Edward Snowden causou tanto rebuliço em todo o mundo, já que revelou que TODOS os algoritmos mais usados permitem que a NSA e os Governos tenham acesso à informação, sem que os emissores e destinatários percebam.

Continuaremos juntando perguntas relacionadas a criptografia, privacidade e segurança da informação para a segunda parte da entrevista! Você pode fazer a pergunta AQUI! 

Php Şifreleme Metodları (Md5, Crypt, Sha1 ve crc32)

Bu dersimizde Php’nin güvenlik ile ilgili bölümlerinden olan Md5, Crypt, Sha1 ve crc32 metodlarını inceleyeceğiz.

Md5, Crypt, Sha1 ve crc32 metodları ne işe yarar?

Web uygulamalarında kullanıcıların parolalarını güvenle saklamak için kullanılan yöntemlerdir.

Kullanım şekli:

md5($sifrelenecek_deger);

Örnek:

<?php $parola=1234; $md5_parola = md5($parola); echo $md5_parola; ?>

(more…)

PHP 的 crc32、crc32b 以及 hash_file

查 PHP 上 CRC32 的資料時，查到讓人噴飯的 comment：

For those who are wondering, there appears to be no fundamental difference between hash_file('md5')/hash_file('sha1') and md5_file()/sha1_file(). They produce identical output and have comparable performance. There is, however, a difference between hash_file('crc32') and something silly like crc32(file_get_contents()). crc32(file_get_contents())'s results are…